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.