Every time a hashed password store gets compromised, people come out of the woodwork and yell things like “They used SHA-1/MD5/DES? OMG that’s so stupid because SHA-1/MD5/DES is broken!” The LinkedIn password breach is no exception.
It’s true that they’re no longer good general-purpose hash functions … except that for the purpose of password hashing they aren’t the weak spot. The types of attacks on these hash functions don’t make it easier to crack hashed passwords. Two things really matter in password hashing: the strength of the input (the password strength) and the time it takes to calculate its hashed version (the work factor).
Here’s a snippet of advice on I give in our “decision point for cryptography” [subscription required]:
In order to create resistance against password attacks given the possibility of weak passwords, the algorithm should use two additional barriers: so-called salts for hashing, which preclude the use of precomputed hash tables, and iteration, which applies the cryptographic function as often as possible within performance and latency requirements in order to slow down the brute force attack.
Note that salting by itself is not enough!
It’s best, of course, to externalize authentication as much as possible. But where passwords need to be stored (and they ultimately need to go somewhere) please do so securely – even if it means having to spend a bit more compute power and endure a bit more latency on authentication.
EDIT: I should add that simply choosing a strong hash like SHA-256 also doesn’t magically make password hashes strong. Although it’s not a bad idea to use strong hash functions, calculating a single hash iteration still takes an amazingly short time.
2nd EDIT: and I should also add that because of practical limits on how many iterations you use, a truly weak password cannot be protected by hashing. 12345 is still a definite no-no.
Category: Uncategorized Tags: