bcrypt vs Argon2: How to Hash Passwords Properly

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?

Practical guidance

For new systems, use Argon2id if your platform has a well-maintained library. If not, bcrypt with a sensible cost remains a solid, widely supported choice. Either is vastly better than MD5, SHA-1, or plain SHA-256.

Good practices

1. Use the library's built-in salt handling; never invent your own scheme.
2. Store the full output string (it embeds the algorithm, parameters, and salt).
3. Benchmark on production hardware and pick parameters that take roughly 100 to 500 milliseconds.
4. Rehash on login when parameters are outdated, upgrading users gradually.
5. Add 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.

Try it: Bcrypt Hash Generator/Checker — free, runs in your browser, nothing is uploaded.

Originally published at ilovekit.app.