Taken from HowtoAuthenticate:
Although it is true that MD5 collisions were found (which is very different than a crack), it is also true that an explicit demonstration of MD5s insecurity failed. Blindly trusting, or dismissing one technology or algorithm without a proper level of understanding can be dangerous to your security. Read up on MD5 at Wikipedia for an introduction.
- LeeO
Well, according to Lee’s reference: “On 1 March 2005, Arjen Lenstra, Xiaoyun Wang, and Benne de Weger demonstrated [3] construction of two X.509 certificates with different public keys and the same MD5 hash, a demonstrably practical collision. [...] Given this, MD5 is definitely not practically collision-free.” SHA-1 is pretty much in the same boat or will be soon.
I’d really recommend against even using SHA-1:
SHA-1 has been broken. Not a reduced-round version. Not a simplified version. The real thing. (SHA-1 Broken, from Bruce Schneier’s blog)
Plus more recent improvements on those attacks here
Right now there is no agreed-upon replacement for SHA-1, as SHA-256 hasn’t undergone sufficient scrutiny, and is essentially the same design as SHA-1 with only minor adjustments. Whirlpool is a promising hash function with a unique “wide-tail” design. It’s rather untested, though.
Building an algorithm-agnostic authentication system seems prudent at this point, perhaps by storing a hash algorithm identifier with the actual hash:
sha256:salt:hash
That way, when a replacement algorithm sorts itself out, switching over will be a simple matter of migrating data.
These attacks on SHA-0, SHA-1, and MD5 do NOT make any difference when it comes to storing your passwords in a database. These attacks only invalidate the usefulness of these encryption methods for digital signatures and the like. Storing passwords as a MD5 or SHA-1 is totally safe. The purpose of this is so that IF someone does get into your database and reads your passwords, they will get nothing but the hash. NONE of these attacks have shown that they can convert a hash into a password. NONE. All they have been able to do is replecate someones digital signature which has NO bearing WHAT-SO-EVER on storing passwords. This is apples and oranges. -fuzzyfree
Just to back up fuzzyfree’s point—if no one has access to the digest, how are they going to be able to craft an input that collides with the correct value? All of the discussions that have been sited relating to any of the digest algorithms being “cracked” are relating to being able to have “MessageA” which would have a digest of “DigestA” and then being able to create “MessageB” that also would have a digest of “DigestA”. -eric
There is no reason not to use SHA2 in any new application you are building. Choosing an algorithm with known flaws (i.e., MD5 or SHA1) when the expense required to use an algorithm which doesn’t have those same flaws (SHA2) is negligible is plain stupid. I understand that there’s been a lot of “omfg teh SHA-1!!!1one is teh crax0red” being tossed around, but the proper reaction to that is not to say “there’s nothing wrong with SHA1; as you were.”
Should people migrate away from SHA1? Depends on how much time and effort that would take. Should people build new systems using SHA1? Categorically no. You don’t need to take my word for it:
But there’s an old saying inside the NSA: “Attacks always get better; they never get worse.” Just as this week’s attack builds on other papers describing attacks against simplified versions of SHA-1, SHA-0, MD4, and MD5, other researchers will build on this result. The attack against SHA-1 will continue to improve, as others read about it and develop faster tricks, optimizations, etc. And Moore’s Law will continue to march forward, making even the existing attack faster and more affordable.
It’s time for us all to migrate away from SHA-1.
Jon Callas, PGP’s CTO, put it best: “It’s time to walk, but not run, to the fire exits. You don’t see smoke, but the fire alarms have gone off.”
http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html
The difference in CPU and memory requirements for SHA1 and SHA2-512 is, given the context of a high-level scripting language like Ruby, trivial. This should be a no-brainer.
OTOH, before worrying about this whole subject, one should worry about other aspects of security on the site. How the password is hashed makes no difference if there are other holes in your app.