"Hashed using MD5"
So a bit like a salted ceasar cipher then. Methinks it might be prudent to swap that bit out for SHA256. 512 would be nice, but probably a bit slow for a busy forum.
Ubuntu Forums are back to normal following a serious hack attack that exposed the usernames, email addresses and hashed passwords of 1.8 million open source users. Parent firm Canonical restored the forums on Tuesday as well as publishing a detailed summary of what went wrong and the broad steps it has taken to beef up …
"So a bit like a salted ceasar cipher then. Methinks it might be prudent to swap that bit out for SHA256. 512 would be nice, but probably a bit slow for a busy forum." -- SHA1 is a fast Hash and shouldn't be used to secure passwords, at least in a PHP environment. PHP's documentation page on the subject suggest the use of Blowfish.
See 'Notes' section:
http://php.net/manual/en/function.sha1.php
Fast Hashing and passwords:
http://www.php.net/manual/en/faq.passwords.php#faq.passwords.fasthash
AFIK in practice any password extraction would rely on a rainbow table style of attack, not on any particular weakness in MD5/SAH1/etc. So the real questions then become:
How much entropy did the salt add?
Are you only trying for a specific user's login?
I have not seen what the salt used is, but have not really looked. For example, if just the email account then it would probably match other attack sites of interest, but if a hash of that plus the user's first log-in time, etc, then it could be usefully big in making a rainbow table impractical.
Anyone care to save my some time and to enlighten El Reg's commentards?
In practice, dictionary attacks are used, not rainbow tables. Salt is of little help:
http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/3/
The hashes in that article were SHA1, not MD5 but they are both fast hash algorithms so they are vulnerable in the same way.
Thats why web applications are evil. They download code to your machine to be executed there every time you access a page. Forums using the old NNTP protocol, which downloads only contents, not applications (especially if you read everything as plain text only) are much more difficult to exploit.
That's either deeply misinformed or deeply misleading. If you're saying (as you seem to be) that the web is a more dangerous place than usenet was, then yes, strictly you are correct. It's also true that our motorways today are much more dangerous than the bridleways of the eighteenth century.
Presumably when you are talking about 'web applications downloading code to your machine' you are speaking of javascript? If so then yes, there is some truth in what you're saying although Javascript runs in a sandboxed environment (the browser) so it's not being executed in the same sense as e.g. a windows .exe.
However javascript is not actually required to make a web application, it is only needed to make a more responsive web application with greater interactivity. Web applications were developed for a long time without any javascript before the advent of ajax, and as such your comment that 'web applications are evil' is patently silly.
Yes, using a browser on a windows machine is considerably more risky than using rn on a soliaris box in the early 90s was, but this is hardly evidence 'web applications are evil' unless you are writing from a 'back to nature, progress is evil, smash the machines' viewpoint, in which case I have to wonder how you managed to make this post in the first place.
(If my understanding is correct:) Technically, this wasn't XSS. XSS means "cross-site scripting", and there was no "cross-site" element involved in this attack. The attacker embedded javascript directly in the announcement he posted and directed the other moderators to. I.e., the script was served from the same server as the website and the cookies, and hence wouldn't (and couldn't) have triggered any XSS protections.
I'm curious as to why vBulletin allows a user with to run "SELECT * FROM USERS;" via a PHP page. I would have thought by now this type of query would be questionable.
Is there a genuine need for this?
Seemingly if a user account (especially an admin/moderator account) is compromised then there is nothing much that can be done apart from limiting what those accounts can do in the first place.
I'm curious as to why vBulletin allows a user with to run "SELECT * FROM USERS;"
Depends how much effort you can put into security.
Yes it's much more secure to allow ONLY stored procedures, but that costs a lot in development time.
All security systems are compromises between security and usability.
"Seemingly if a user account (especially an admin/moderator account) is compromised then there is nothing much that can be done apart from limiting what those accounts can do in the first place"
That's very true. The issue is that vbulletin is really not a very security-minded application, it's a 'kitchen sink' forum application which is designed to provide any features a forum owner might want. Basically if you have admin access to it you have been given full access to the server, especially through the 'hooks' mentioned in the article - at the absolute minimum the Ubuntu sysadmins really should have disabled that feature.
The mistake Ubuntu made was being lazy and choosing to use vBulletin rather than writing their own custom forum application, compounded by their failure to properly review the vbulletin configuration from a security perspective - not a very big project given the wealth of development talent available to them. Considering that they are asking he public to stump up 30 million dollars to help them develop a smartphone right now they really need to take a little more care.
And I say this as someone who's really not anti-ubuntu, or anti-vbulletin, I have used the former at home and the latter at work.
they now force user to use a "Single Signon" to access both their Ubuntu1 drop-box as well as the BBS
this is not regarded as a "best practice" : anything of a sensitive nature -- should have a separate password. and your drop-box may be sensitive -- depending on what you use it for
I don't know ... isn't single-sign on backed by two-factor authentication? AIUI (and I haven't used this on Ubuntu services) with something like OpenID you put in your login request at one service and then go to another page (on your authenticating server) to OK that request. Barring some sort of browser flaw that lets a rogue site access the master details on the authentication page (which probably means you're owned anyway, so even individual passwords wouldn't be safe), I can't see how it's a big problem.
Of course, I'm only talking about single-sign on for sites that aren't that important. Of course you wouldn't want SSO for protecting anything of value.
You shouldn't be storing sensitive things on Ubuntu One anyway... You don't know who could be looking at it at the other end!
The login thing seems to work. I logged in with my U1 account, and the forums came up with my (different) username. Slightly annoying though is that it didn't land me back on the page I started from, but instead when to the full list of forum categories... That could get annoying!!