Enough with the Salts: Updates on Secure Password Schemes
It's easy to say "use bcrypt" or "use scrypt," but I think it's important to acknowledge the challenges of deploying those functions in large scale high performance environments.<p>It's straightforward and effective when password hashing happens client-side (like local encryption for a bitcoin wallet), but using scrypt or bcrypt <i>server-side</i> at effective difficulty levels will either destroy your L1/L2 cache or exceed your CPU budget.<p>In practice, from what I've seen, this means scrypt is never used, and bcrypt is used with a work factor that's tuned low.  I think this is just a fundamental asymmetry, and that at the end of the day people use bcrypt so that they can say "we used bcrypt!" and get a nod when their entire user database is compromised, even though it provides very little value the way it's deployed.