Edward Z. Yang wrote:
implementing cryptographic hashes is not difficult at
all
as long as you understand the algorithm and a good battery of unit tests
to make sure your implementation is working properly.
Yes, and jet turbine maintenance is not difficult at all as long as you
understand their construction and have a good battery of pre-flight
tests to make sure they're working properly. Yet you wouldn't feel very
comfortable grabbing a random person off the street, handing them the
manual, and having them go to town on the engines of your 747.
It's trivial to introduce all sorts of subtle bugs when creating new
crypto implementations -- we've seen this happen time after time -- so
unless there's a particularly compelling reason to reimplement from
scratch, sticking with something that's already out and has had many
eyeballs looking at it is almost always the correct choice.
But if we're going to go the trouble of
migration (small trouble, but trouble that requires DB schema changes
nonetheless (be they formal or informal)), we might as well do it right.
I remember one security expert saying that there is no smoke yet, but
the alarm bells have gone off for SHA-1 and it's time to walk (not run)
for the exits.
FUD. Talk of "doing it right" and "alarm bells having gone off" is
meaningless without a threat model. New uses of SHA-1 are rightly
discouraged in protocol design, where collisions directly translate to
potential problems, but password hashing?
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 Krstić <krstic(a)solarsail.hcs.harvard.edu> | GPG: 0x147C722D