Drupal.org & group.drupal.org password disclosure

Published: 2013-05-30
Last Updated: 2013-05-30 04:12:54 UTC
by Mark Hofman (Version: 1)
5 comment(s)

The Drupal security teams have identified a breach in the environment that has disclosed passwords.  As their notification here --> https://drupal.org/news/130529SecurityUpdate  states most of the passwords were salted and hashed, older passwords were not (although common practice is to store the salt value in the same table as the password, so that might not actually help much).  According to the update they are still investigating what else may have been accessed.  If you have one of those accounts happy password changing.  If you use that password anywhere else (and of course you don't) you might want to change that whilst you are at it.  

From the perspective of letting people know I must say I'm quite impressed.  They notified fairly early on, they provide some details of the incident, steps to take, actions they are taking.  From the breach notifications I have seen recently this is one of the more complete and useful ones.  

Cheers

Mark H

Keywords:
5 comment(s)

Comments

I agree. Drupal has done a nice job of communicating details about the incident. Other companies should take notice that Drupal's response will build and enhance trust with their community vs. a secretive/defensive response (most other companies) which communicates weakness and does nothing to build trust.

In the ideal world, security incidents should be reported openly like traffic/crime statistics.

Good job Drupal.
It doesn't really matter that the salt is known? I though it was merely to make comparison with precomputed hashes impractical, and also hides cases where different users have the same password.
Actually yes, knowing the salt makes it easier to break a chosen hash than it would have been otherwise. But the use of a random salt (even if it is known) would make it harder to shortcut the search, by trying to break 'any' hash and not caring which.
@Steve, Doesn't help much as in help protect the password. If I have the salt and the resulting hash sitting in the same table and I have that table I can generate the hash, but yes pre computational attacks may not work, brute force obviously still will and will likely result in a fair number of passwords being "guessed" correctly.
I don't see it being practical to separate the salt anyway - if you properly protect the hashes, they'd be available only to whatever does the password checking (but that wasn't the case in this breach). The same code will need access to the salt, so storing it elsewhere is just... obfuscation really.

Better to use a stronger hash algorithm and/or number of rounds. The rate that people can produce SHA256 hashes with GPUs now is alarming. I'd hope for SHA512 ($6$) with the default 5000 rounds, or Blowfish ($2a$) with at least 2^4 rounds. Drupal's announcement doesn't quite go into this amount of detail but PHPass will typically use the latter or better.

Diary Archives