On 1/22/07, Ivan Krstić krstic@solarsail.hcs.harvard.edu wrote: [snip]
Generally, the only password hashing scenario in which the choice of algorithm makes a difference at all is an offline attack once the password table has been compromised, at which point, the difference between one algorithm and the next is nothing more but how long you can hold off a brute-forcing attacker. And for that, without preimage attacks, the known MD5 and SHA-1 flaws make about zero difference for any practical purpose.
Ivan is right on in his statements here.
There might be good reasons to move.. for example, as part of an overall effort to stop using legacy hash functions throughout the software... or better, to change to a system which supports client side hashing.
None of the pre-existing MD5 rainbow tables will do a lick of good against mediawiki because of the weird legacy inspired H(s+'-'+H(P)) that we use.
Frankly, we could probably be using classic unix crypt() for this application. Hashing our server side passwords is useful to make it less attractive for someone to steal the database, and perhaps keep a curious developer from doing something actually useful like publishing a list of accounts with the same password.
Once we've succeeded in making sure that attacking the database of passwords is no longer the lowest hanging fruit, we're pretty much done... Taking the extra effort to add lots of additional security will only risk adding additional vulnerabilities.
(/me waits for someone to notice my above H(s +'-'+H(P)) above and cry about the minor precomputation a smart attacker can do to reduce the workload from 2*users*passwords MD5s to passwords + passwords*users MD5s)
If someone wants to add something that will substantially improve security which requires no substantial changes, ... build something like Google's password strength indicator for the password change page. :) (bonus points for pure js rather than ajax based)