On 1/22/07, Ivan Krstić <krstic(a)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)