Storing passwords safely is one of the few areas where doing the standard thing well matters more than being clever. The standard thing is to use a purpose-built, deliberately slow password hashing function, and never a general-purpose hash such as MD5 or SHA-256 by itself.
What a password hash needs
- Slow by design: hashing should cost enough that guessing billions of passwords is impractical.
- Salted: a unique random value per password, so identical passwords hash differently and precomputed tables are useless.
- Tunable: a work factor you can raise as hardware improves.
- Memory-hard (ideally): making GPU and ASIC attacks more expensive.
bcrypt
- Around since 1999 and available in essentially every language.
- Controlled by a cost factor: each increase of 1 doubles the work. OWASP suggests a cost of at least 10, and many teams use 12 or more, tuned so a hash takes a noticeable fraction of a second on your server.
- Only the first 72 bytes of the password are used, so very long passwords or passphrases are truncated. Some libraries pre-hash to handle this.
- Not memory-hard, which makes it somewhat easier to attack with specialized hardware.
Argon2id
- Winner of the Password Hashing Competition in 2015; Argon2id is the recommended variant.
- Has three parameters: memory, iterations (time), and parallelism.
- OWASP's minimum configuration is roughly 19 MiB of memory, 2 iterations, and 1 degree of parallelism, with other combinations offering similar strength.
- Memory-hardness makes large-scale cracking substantially more expensive.
Which should you choose?
Good practices
- 1Use the library's built-in salt handling; never invent your own scheme.
- 2Store the full output string (it embeds the algorithm, parameters, and salt).
- 3Benchmark on production hardware and pick parameters that take roughly 100 to 500 milliseconds.
- 4Rehash on login when parameters are outdated, upgrading users gradually.
- 5Add rate limiting and multi-factor authentication; hashing doesn't stop online guessing.
Frequently asked questions
+Is bcrypt still secure?
Yes, with a sufficient cost factor it remains secure and widely used, though Argon2id is preferred for new designs.
+Why not just use SHA-256 for passwords?
It is designed to be fast, which lets attackers test billions of guesses per second. Password hashes are deliberately slow.
+What is a salt?
A unique random value added to each password before hashing so identical passwords produce different hashes.
+What bcrypt cost factor should I use?
At least 10, and commonly 12 or higher, tuned to take a noticeable fraction of a second on your hardware.
Bcrypt Hash Generator/Checker
Free, runs in your browser — nothing you enter is uploaded.