Drupal hacked, resets passwords after millions of accounts exposed Hackers are believed to have compromised the accounts of millions of users operating or developing the Drupal open-source content management system (CMS). The Drupal Association says an individual or group has gained unauthorised access to the accounts on its Drupal.org and groups.drupal.org sites. Information exposed …
The salt doesn't make that much difference in a case like this. All it will do is slow them down a bit.
You don't take somebodies account and then try to crack the password. What you do is use pick a password and then encrypt it with each accounts salt to see if the password matches. It's inevitable that a dictionary attack will reveal many passwords when millions of accounts are involved.
Curious... I'm seeing Ars linked to a lot more recently and yet whenever I read most of their stories (let alone the comments) I still get a strong feeling that the content is being heavily dumbed down to appeal to a wider audience.
Is it just the stories I've bothered to read (i.e has most of the content improved) or is El Reg just getting visited by more of those who believe they understand tech but don't feel the need to understand how it works?
Just look at the comments in that link, there are (undoubtedly) a few who know what they're talking about but most don't seem to have even the beginning of an idea. As for the content, surely most real techies already understand why a simple checksum (even if salted) is a piss poor password storage mechanism. You need to up the cost of trying dictionary and rule based attacks so that fewer hashes can be computed per second. If nothing else it gives you a little more time, and if the cost/benefit is out of balance the attacker may even move onto lower hanging fruit.
It sounds like you're thinking of the standard Unix password scheme (apologies if I've got that wrong). But for a web password, you're free to use your own methods, which could easily include a salt that is generated rather than stored by a separate hashing process from unchanging user data (perhaps the user name or a timestamp of when the user was created).
The salt has to be stored otherwise when you enter your password they would have to encrypt it with every possible salt in order to test it against the stored hash. The salt itself can be any length you want. In addition to using a salt you can also use multiple iterations of the hash so as to increase the cost to the attacker, but again, both the salt and the number of iterations have to be stored so as to enable password verification.
The early Unix password scheme only used a 12 bit salt which isn't sufficient today.
@Chris
Whilst you're correct, the salt could simply be any data you have on the user, doing that offers very little real protection. A good attacker will take the time to work out your salting mechanism, and once they do you're back to square one. oclHashcat-plus will also attempt to recover the salt if you don't know it, though its always going to take quite a while, and you'll need a goodsized dump of hashes to maximize your chances.
Good strong passwords are the best protection, but the ones most resistant to cracking are nigh on impossible to remember. The problem is, some users' idea of 'strong' just doesn't match up to the capabilities of the systems being used to crack hashes.
You're right in principle, but in practice it means the difference between a hacker simply copying one or two passwd files (ideally that shouldn't be easy, but that seems to be what has happened here, and occurs all too often), and their having to gain complete ownership of your web server, identifying the code containing your 'personal' salt-generation software and then disassembling it (the source code is held on a USB stick in a safe). I wouldn't propose this mechanism for the protection of military grade secrets, but I think for a list of passwords to a standard web site it's more than good enough.
Of course, most people will just use standard off-the-shelf code for their password algorithm, in which case a smart attacker should be able to ascertain which one and then, as you rightly say, all bets are off unless you can train your users to adopt 'strong' passwords (good luck with that!)
@Chris as long as the data you're using as the salt is unique to the user (so that it's harder to identify any sort of pattern) then its certainly no less secure than the traditional hash:salt that most use. But if you've a large enough username it may take less effort to guess your salting mechanism than you think.
With a large userbase, there's a high probability that at least one user will have used a poor password. I'd run a crack attempt on the basis that its just a straight hash, then try another using the username as the salt, rinse and repeat with any other possible salt. The processing cost of hashing the 'salts' is small so I'd try that too.
Where that falls down, of course, is if you've taken the step of taking a few passes when generating the hash. The cost to me rises dramatically. But that's also not the average implementation, most who use salts are still only taking one pass at the hash (and worse, some are still using MD5).
What I'm getting at is that treating a salt as a secret cannot be the sole defense. It's security through obscurity and may not be as hard to ascertain as you think. Increasing the processing cost to run a dictionary attack is your best defense (aside from lecturing users )
All it will do is slow them down a bit.
For the rainbow table case, say, a password is salted with a variable length of 5 -10 chars made of digits, lower or upper English chars. The total number of possible salts would then be given by 62^5+62^6+..+62^10=62^5*(62^6-1)/61=853,058,371,851,163,296.
As for the "1234" and "passw0rd", let them be cracked. It would actually be pretty good.
Within an hour of getting the e-mail from Holly my mailbox started to collect SPAM at quite an alarming rate. The Drupal forums appear to be beset with users requesting their accounts be closed and deleted.
Shit happens, I'm certainly not going to stop using the platform for one incident.
what if you found out they didnt hash or salt the passwords, would that be enough?
I mean, an incident, fine, they lost the db, fine, reset everything, fine, if you find out they stored everything in the open? still fine?
lets see what they say, I'm sure the next couple of days they'll tell us...they have little choice but to do so otherwise the situation will just keep going on and on.
For me as a user it's not a biggy - I can use Drupal's CMS without having to have an account on their site.
On the other hand, core and module developers at Drupal clearly have permissions that enable them to change core and module code. If either suffered a compromise that's a lot more serious. I'm going to be following the story for sure.
According to Wikipedia:
'Drupal.org has a large community of users and developers, with over 913,000 user accounts and over 22,600 developer accounts (As of December 2012)'
The user accounts are for users who want to participate in the forums, post bugs etc.
The developer accounts are for the developers who have gone through the fairly arduous process of creating a module which is both substantial and passes strict reviews. They are then allowed to create modules which are uploaded to the Drupal module database.
In fact, only modules which have been created by authorised developers are allowed on to Drupal. Of course, they're not all perfect but this system does help keep the quality up.
Somebody could have made off with a treasure trove of Public Sector Information in the Public Domain. My guess is Starbucks. Maybe they detected a smoker somewhere in the various Family Trees in the Western Hemisphere several generations back and wanted to prove their machismo.
The Drupids - (Druids who run Drupal) - are right to say "Open Source, Open, O-P-E-N, Open"
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
