> You should hash passwords (...) You should not hash passwords. You should never hash a password. You should use an appropriate key derivation function (bcry

> You should hash passwords (...) You should not hash passwords. You should never hash a password. You should use an appropriate key derivation function (bcrypt, scrypt, PBKDF2). Key derivation functions are designed to address the issues you note and many more. Now, let me give a few choice tptacek quotes on this: >The socialbookmarkosphere is abuzz with talk of “rainbow tables”(...) This really freaks me out. If the “advanced” pole of your threat model is “rainbow tables”, stop working on your social shopping cart calendar application right now: I can’t trust you with my Reddit karma score, let alone my credit card number. > Rainbow tables are easy to beat. For each password, generate a random number [... and do what you said to do ...] Cool, huh? Yeah, and Unix crypt —- almost the lowest common denominator in security systems —- has had this feature since 1976. If this is news to you, you shouldn’t be designing password systems. Use someone else’s good one. --- I'm banging on this drum for a very simple reason: even if you are smart enough to know that salt+general purpose cryptographic hash function isn't good enough, when you say "hash" programmers that aren't smart enough are getting the wrong message. And if you do believe a "hashing algorithm with a long random salt" (which I translate to "general-purpose cryptographic hash function, such as SHA/RIPEMD + a nonce") is sufficient to store a password... well, let's hope you don't.