MD5crypt Password Scrambler Is No Longer Considered Safe 212
As reported here recently, millions of LinkedIn password hashes have been leaked online. An anonymous reader writes "Now, Poul-Henning Kamp a developer known for work on various projects and the author of the md5crypt password scrambler asks everybody to migrate to a stronger password scrambler without undue delay. From the blog post: 'New research has shown that it can be run at a rate close to 1 million checks per second on COTS GPU hardware, which means that it is as prone to brute-force attacks as the DES based UNIX crypt was back in 1995: Any 8 character password can be found in a couple of days. The default algorithm for storing password hashes in /etc/shadow is MD5. RHEL / CentOS / FreeBSD user can migrate to SHA-512 hashing algorithms.'" Reader Curseyoukhan was one of several to also point out that dating site eHarmony got the same treatment as LinkedIn. Update: 06/07 20:13 GMT by T : An anonymous reader adds a snippet from Help Net Security, too: "Last.fm has piped up to warn about a leak of their own users' passwords. Users who have logged in to the site were greeted today by a warning asking them to change their password while the site investigates a security problem. Following the offered link to learn more, they landed on another page with another warning."
What about Debian? (Score:2, Interesting)
"... RHEL / CentOS / FreeBSD user can migrate to SHA-512 hashing algorithms."
That's fine and dandy and all, but what about King Shit Debian? Pretty much all of my systems run something Debian-based in one form or another. Is this a simple change for Debian users too?
Unsalted hashes are worse. (Score:5, Interesting)
It astounds me that Linkedin and eHarmony used unsalted password hashes. That's much worse than using md5 (and, yes, you shouldn't use md5, but, still, first things first).
From the Linkedin Press Release :
The passwords are stored as unsalted SHA-1 hashes,
Come on, guys, get up to at least 1978 [bell-labs.com] in your security policy.
Re:Are you sure SHA-1+salt is enough for passwords (Score:4, Interesting)
SHA-1 is not sufficient, but the summary refers to SHA-512, which is in the SHA-2 set [wikipedia.org]. Now whether SHA-2 is sufficent, or if developers should be migrating to something like bcrypt [wikipedia.org] or SRP [wikipedia.org] is a bigger conversation.
In any case, while I would never tell someone to use MD5, the lack of a salt is much more egregious and made the leak much worse than it had to be.
Re:Authentication and Identification servers (Score:4, Interesting)
Machines that are accessed by users should not be the same servers storing the account security data.
Get real. I run several sites that have user accounts. My infrastructure budget is $10/month for a hostmonster account. There is no way to have a separate server for account info without spending more money, which I am not willing to do. I use SHA-256 to store salted passwords. That is as good as it is going to get for most sites, and it is good enough.
The problem with linkedin, is that they are run by morons. Storing unsalted passwords with weak encryption should be considered criminal negligence even for a hobbyist website. Reasonable security would have cost them nothing.
Re:Are you sure SHA-1+salt is enough for passwords (Score:4, Interesting)
Algorithms designed to burn CPU, like PBKDF2 recommended in the article, are great if used correctly.
The important thing to remember is that you want to make the client burn CPU, NOT the server. If you let the client trivially initiate 10 http requests that cause a server's CPU to peg for 1 second each, you've created a nice DoS vector.
Are there any existing Javascript crypto libraries that safely offload this work to the client?
Re:Brute-force was solved decades ago. (Score:5, Interesting)
1) server + http is stateless; it is not trivial to delay attempts every second. You would have to maintain a database of accounts and failure timestamps. On occasion, you'd have to scrub that database too. Not difficult to implement but I suspect few do. Busy distributed sites have more complications as this database may need to be in sync between servers; creating a possible bottleneck and another attack vector.
2) An attack on 100s of accounts could rotate between accounts to get around the time limit. So now you are storing a short history in that database; or tracking an IP address but not being too aggressive with the IP due to NAT users... and bot nets do not have as much trouble getting IP addresses.
3) Security holes. Some simple little add on to your website written in PHP just compromised your password database. The server may still be "secure" but the data could leak out and you may never know about it. Your password hashes are now on the internet with ZERO time delay between password attempts and any method known to man can be employed in parallel against those password hashes. Many people use the SAME password for all their accounts so one can be motivated to crack them even everybody later changes their passwords they probably keep the old ones in use elsewhere.
4) Some users have EMAIL ADDRESSES for account names it becomes easy to find that person again. Also, identification information may leak as well. Some sites produce different errors for unknown account names so then you know they have an account - especially if the account name is an email address. Even with a 1 second delay, I can quickly (in parallel) check a huge list of email addresses to see who has accounts with XXX with animals and kids .com. In addition, one has enough to send phishing emails...
5) Lost password questions. These questions are usually pathetic and tolerant of variations on input. This provides an easier password to crack probably without as much protection. 1 second delay will do nothing against "What is your mother's maiden name?"
So:
Learn something from DES, MD5 and soon SHA -- use bcrypt hashing!
Keep a timestamp database to filter out simple attacks and identify accounts under attack and log more data.
Do not use emails for account names. Encrypt identification (emails) in the database; store the keys outside the database's reach.
Forbid stupid passwords. Probably BAD to have secure questions at all.
Do not mindlessly ban the use of autocomplete since it allows many of us to generate long random passwords. Do not limit the length of passwords or the characters used; too many sites are overly restrictive.
Do not output errors that leak information.
Re:it is about compute speed, not hash strength (Score:4, Interesting)
The argument is that "we can do 1 million hashes in one second on a GPU, thus we can perform a dictionary attack in just a few days." It is an argument about execution speed versus size of the dictionary. The size of the dictionary is limited by the human brain, and is not going to change any time soon. The execution speed is expected to decrease as a function of Moore's law, GPU, etc. The solution cannot be to move to SHA1, or even SHA256, because these algorithms don't take much longer to run than MD-5. They can't, because they are used in scenarios where servers have to process millions of messages.
The solution is probably to do something special for password storage. Use salt of course. But also do something like "run SH-xxx N times" where N is a number that grows larger as Moore's law progresses.
True, all true, but entirely missing the point. Never store any customer data at all unencrypted, even password hashes. There are many ways to have your data pwnt, but bulk copy of the data at rest is the easiest and most common. That data (bulk data at rest) should never be unencrypted, ever.
Re:Are you sure SHA-1+salt is enough for passwords (Score:4, Interesting)
And the hash is the password again...
If I have stolen $hash from server, I won't need to break that hash to emulate the user.
I just need to get challenge and return hash($stolen_hash + challenge) to the server. Congratulations, you re-invented saving "plaintext" passwords! ;)