Sophos Cloud Optix
Note: I have made some edits for accuracy based upon input from my colleagues and commenters.
First the bad new. On Monday, Mozilla, the developer of popular open source applications like Firefox and Thunderbird, announced that a database containing usernames and password hashes belonging to users of addons.mozilla.org had been posted publicly by accident. If you registered for an account on addons.mozilla.org and you are one of the 44,000 users who might have been affected by this accidental disclosure, you already should have received an email notification from the Mozilla security team.
Is this simply another story of data leakage in a sea of lost usernames and passwords? Not exactly. Mozilla stored passwords set before April 9th, 2009 as MD5 hashes. While MD5 can be used to securely store passwords, it is unclear how MD5 was utilized the Mozilla infrastracture. Fortunately, Mozilla did not store passwords in plain text.
The good news? Mozilla audited their logs and determined that the only person outside of Mozilla who accessed the content was the person who disclosed the accidental publication to them through their web bounty program. Mozilla has deleted the passwords of all 44,000 accounts that were stored in MD5 format from the addons site regardless of whether they were exposed or not.
Newly created passwords will not be as vulnerable to a similar disclosure. Since April 9, 2009, Mozilla has used SHA-512 with per-user salts to store password hashes. This hashing algorithm provides a significant improvement in security for addons.mozilla.org account holders.
If you were one of the unlucky recipients of one of these emails, make sure you were not using the same password at Mozilla as you are at other sites. While Mozilla is quite confident no one other than the person who reported the incident had access to the file, if they are wrong or the discloser is not trustworthy, your other accounts may be at risk. Remember, unique passwords are a requirement, not a luxury.
I commend Mozilla for their response to this incident, but it does leave a few issues we need to consider. How did they accidentally publish files containing usernames and password hashes? I asked the security team and was referred to the blog post explaining their response.
Mozilla made the right decision in 2009 to begin using a more secure system (SHA-512 with per-user salts) moving forward, but in hindsight might have prompted all of their users to migrate to the more secure hash before this incident.
This is interesting, and probably even important, but it still doesn’t excuse or explain how the account details were compromised in the first place. Account databases, even those containing strongly salted and hashed passwords, aren’t supposed to be world readable.
Oh, and if you do receive an email warning you that your password might have been compromised, whether from Mozilla or anyone else, don’t click on any links in the email to go and update your password. That’s a scammer’s trick. Always remember to make your own way to the relevant password-change page.
Creative Commons image of Jacob Appelbaum’s (<– It's safe to bypass this warning, promise!) t-shirt from 25C3 courtesy of Security4All’s Flickr photostream.
yes, they *could* have prompted users to switch over to the
new method, OR they could have switched them over silently as the
users logged in, OR they could have simply combined the existing
hash method with the new salted hash method (ex. HASH{final} =
SHA512(SALT + MD5(PASSWORD)) ) and migrated all accounts without
input from the users at all.
Good points Kurt. There are a few other points I may add to the article as well. Thanks for your input 🙂 Have a happy new year as well.
Chet
"MD5 has cryptographic weaknesses that permit creation of the same hash from multiple strings."
Hash (here MD5) collisions have no impact on disclosures such as this. If you successfully find a hash input that collides with the password, it's useless. You cannot use that collision to log in anywhere else or even find the original password.
Additionally, finding a collision for a specific password is computationally wasteful and makes the problem exponentially more time consuming.
The concern is only bruteforcing hashes of passwords with low complexity in a reasonable time or against a rainbow table (an existing database of hashes). This can include salted passwords if the salt is also not sufficiently complex. Salts were originally conceived to prevent successful dictionary attacks (common words, etc).
Thank you for the feedback Ryan, I have made some changes that hopefully reflect your concerns.
Chet
100 rounds of MD5 hashing is vastly superior to a few rounds of SHA-512 hashing.
What is unclear in the case is if/how they were salting, and if/how many rounds they used. I have made some updates to not imply that MD5 cannot be used safely, hopefully that removes this incorrect implication.
Thanks,
Chet
But isn’t the point that, with the exception of SHA being a bit more expensive to hash (and thus the offline attacks being marginally more expensive), the distinction between SHA and MD5 is basically irrelevant here?
I think you’re bringing up a generally good rule of thumb (“don’t use md5 if you don’t understand crypto enough to know whether md5’s known weaknesses are an issue for you”) and treating it as gospel (in this case, md5’s known weaknesses are *not* an issue).
Kudos for using SHA-512 with per-user salt. I guess until the next SHA algorithm is unveiled in 2012 that's about as good as it gets (well, better with more rounds). I recently did the same to a web application I work on.
But the fact remains, if users chose one of the most popular bad passwords and use it on multiple sites, no hashing algorithm is going to protect them if the database from any one of those sites is stolen. The attacker need only guess (from a list of say, the 1,000 most popular passwords), hash the guess with the appropriate algorithm and salt, and compare the result to the value in the database. Take 1,000 guesses for each account and move on to the next. It seems silly to call such an attack "brute force" but if users choose from a small enough pool of popular passwords, they make it too easy.
In the end, you can't protect users from themselves. If they use a completely different and random password for each of their accounts, it doesn't matter so much if one of those accounts is hacked – at least the damage is contained. If not, well, sometimes people reap what they sow.
About 1 in 60 of my accounts reports that the password database was leaked every year. Probably several more are leaked without reporting it. If I used the same password for multiple accounts… well, I'll leave that to a statistician, but ultimately it's up to users to protect themselves. Only a good personal password manager can save them. KeePass FTW!