- Do not use a single pass of any hashing function to store passwords.
- Do not fail to use a random salt in the 8-16 byte range.
- Do not use reversible encryption to store passwords.
- Do not use the password precisely as entered as your encryption key.
Instead, when the user is selecting a keyword/passphrase
- Generate a cryptographically random 8-16 byte salt
- Use PBKDF2, BCrypt, or SCrypt with said salt and as large an iteration count/work factor as your processors can handle to create a password hash
- If you use PBKDF2 in specific, do not request a larger output than the native hash size (SHA-1 = 20 bytes, SHA-256 is 32 bytes, SHA-384 is 48 bytes, and SHA-512 is 64 bytes), or you increase the comparative advantage an attacker has over you, the defender.
Then in your database, you store that user's particular:
- Salt in the clear
- Iteration count/work factor
- So you can easily change/upgrade it later
- Resulting password hash
- Version of authentication protocol - this would be 2, probably, or 1.
- So you can easily change/upgrade it later if you move from this method to NewWellKnownMethod later
When the user wants to authenticate to your system, you:
- Retrieve their version, salt, iteration count/work factor, and resulting hash from the database
- Hash whatever keyword/password they just entered with the salt and iteration count/work factor from the database.
- Compare the result you just got with what was in the database; if they're the same, let them in.
- Advanced: use a constant time compare, so it doesn't just quit trying if the first byte is different, to reduce the vulnerability to timing attacks.
Please read How to securely hash passwords?, of which Thomas Porrin's answer is currently the most commonly referred to Stackexchange treatise on password hashing, and certainly the best I've seen so far.