back to article 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 includes …

COMMENTS

This topic is closed for new posts.
Facepalm

But wait, I thought the passwords were hashed?

0
0
Pirate

Doesn't matter

Given a couple of days a specialist password hacker can match around three quarters of them.

http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/

2
1
Silver badge

Re: Doesn't matter

Which is why you must salt them in addition to using a hash function (preferably a better one than MD5).

0
0
Anonymous Coward

Re: Doesn't matter

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.

1
0
Anonymous Coward

Re: Doesn't matter

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.

0
0
Anonymous Coward

Re: Doesn't matter

"What you do is use pick a password and then encrypt it with each accounts salt to see if the password matches"

How would they know the salt, especially if it changes for every user?

0
0
Bronze badge

Re: Doesn't matter

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.

0
0
Silver badge

Re: Doesn't matter

> How would they know the salt, especially if it changes for every user?

It has to be stored with the password, so that normal password validation can work. It's not secret, just a way to make the computation harder.

0
0
Silver badge

@Phil

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).

0
0
Anonymous Coward

@Chris

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.

0
0
Silver badge

Re: @Phil

@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.

0
0
Silver badge

@Ben

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!)

0
0
Silver badge
Thumb Up

Re: @Ben

@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 )

0
0

Somewhat annoying

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.

0
0
Facepalm

Re: Somewhat annoying

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.

0
0

Re: Somewhat annoying

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.

0
0
Anonymous Coward

Re: Somewhat annoying

Drupal.org runs with https://drupal.org/project/phpass so how passwords is stored is known already...

0
0

Re: Somewhat annoying

We already know because they emailed us a few days ago. The passwords were salted and encrypted.

0
0

news like this is getting really annoying!!!

0
0
Silver badge

Are there really ....

... millions of accounts on drupal.org?

0
0
Silver badge

Re: Are there really ....

I agree, I don't understand the figures. There might be Millions of people using Drupal but Millions on their website seems quite dubious.

0
0

Re: Are there really ....

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.

0
0
Silver badge

Re: Are there really ....

Thanks bailey86. I guess 93.56% of 1 million wasn't dramatic enough as a headline

0
0
Fai

Obligatory xkcd reference: http://xkcd.com/936/

I'm wondering how long it would take to decrypt a bookload of bcrypt-hashed accounts (assuming Drupal used bcrypt by default with phpass), though the groups site using an "older" hashing algorithm would make that a moot point.

0
0
Pint

Erm..

I can't remember my password so I'm safe, right?

Cheers to the weekend!

0
0
Bronze badge
WTF?

Wohoo

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"

0
0
This topic is closed for new posts.

Forums