I just thought about another reason why bcrypt might be more useful for a web app than for hashing OS passwords: - when a webapp loses its user table, the devs

I just thought about another reason why bcrypt might be more useful for a web app than for hashing OS passwords: - when a webapp loses its user table, the devs will be responsible for compromising thousands of password (which user often re-use elsewhere). This is what happened with the Gawker hack and the recent lulzsec database dumps. - when somebody accesses your /etc/shadow file, he likely already has root access to your machine, so you are pretty much owned anyway. Protecting your password might help a little, but it's less useful than in the above case. tptacek talked a little about this in one of the posts I linked above: http://news.ycombinator.com/item?id=1091445 http://news.ycombinator.com/item?id=1091445 ------------------------ Now, to address your point: stretched SHA512 (SHA512 iterated 5000 times) is indeed a lot better than calling SHA512 once. But bcrypt still has some advantages over it by design, which makes it even better for password hashing. Some links: http://news.ycombinator.com/item?id=1091465 http://news.ycombinator.com/item?id=1091465 http://news.ycombinator.com/item?id=995685 http://news.ycombinator.com/item?id=995685 http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html http://chargen.matasano.com/chargen/2007/9/7/enough-with-the... ------------------------ Regarding your second link (Schneier on SHA-512 variants), I don't see anything about bcrypt or password hashing there. He talks about the advances of hash functions, but those are fast hash functions. Fast hash functions are very useful in cryptography, but they are the opposite of what you want for a password hashing scheme.