Why password hashing matters
Password hashing is a security control that turns a password into a value that is safe to store even if your database becomes compromised. Plain cryptographic hash functions like SHA-256 are fast and were not designed to slow down attackers, so they allow mass cracking with GPUs or ASICs. Specialized password-hashing functions add deliberate computational cost and sometimes memory cost so that brute-force and dictionary attacks become expensive. Choosing the right algorithm and parameters directly affects how fast an attacker can try guesses and how long your infrastructure will hold up under that pressure.
What is bcrypt and how it works
Bcrypt is a password hashing function based on the Blowfish cipher and has been in wide use since the late 1990s. It uses a per-password random salt and a configurable “cost” parameter that increases the number of internal iterations, making hashing slower as you raise the cost. Bcrypt produces a string that embeds the algorithm identifier, cost, salt, and hash, which simplifies storage and verification. It resists simple GPU acceleration better than raw hashes because of its internal structure, but it is not strongly memory-hard: modern high-memory attackers still find ways to accelerate it. Another practical limitation is that bcrypt truncates input passwords at 72 bytes, which can surprise implementers who do not normalize or handle long passphrases properly.
Common alternatives and what they bring
Several alternatives to bcrypt are commonly used today. The right choice depends on compatibility needs, performance, and threat models. Below are the most common alternatives and how they differ in practical terms.
Argon2
Argon2 won the Password Hashing Competition and is designed specifically to be memory-hard and configurable across three dimensions: time (iterations), memory (amount of RAM used), and parallelism (threads). Argon2id is the recommended variant for password hashing because it balances resistance to side-channel attacks and GPU/ASIC parallelism. Because it requires significant RAM, Argon2 makes attacks using many low-cost GPUs or ASICs much harder and more expensive. Libraries implementing Argon2 are widely available, including in libsodium and dedicated bindings for many languages.
scrypt
Scrypt is an older memory-hard function designed to make hardware attacks expensive by requiring a lot of memory during computation. It remains a reasonable choice where Argon2 is not available, but it tends to be less flexible and newer designs like Argon2 offer better tunability. Scrypt parameters typically include a CPU cost, a block size factor, and the parallelization factor, and tuning them correctly is important to get the intended memory usage.
PBKDF2
PBKDF2 is an HMAC-based key derivation function standardized by NIST and widely supported across platforms and languages. It uses a salt and iteration count to increase computational work. PBKDF2 is a good choice where compliance or platform compatibility is required, such as older enterprise environments or hardware security modules that only support standardized algorithms. Its main downside for modern threat models is that PBKDF2 is not memory-hard, so it is more vulnerable to attackers using fast, parallel hardware than Argon2 or scrypt.
Practical comparison: security, performance, and compatibility
All of these functions aim to slow down attackers, but they differ in how they do it. Bcrypt slows attackers by increasing CPU work; PBKDF2 does the same via more iterations. Argon2 and scrypt add memory costs in addition to CPU work, which makes scaling attacks with GPUs or custom hardware substantially more expensive. In terms of compatibility, bcrypt and PBKDF2 are supported almost everywhere, making them simple choices for many existing systems. Argon2 has excellent support in modern libraries and is recommended for new projects when you can control dependencies. Scrypt sits between those two: better than PBKDF2 for some threat models but less modern than Argon2.
Recommended choices by scenario
When picking a password hash, consider whether you’re starting fresh, maintaining an older system, or working under compliance constraints. For new applications where you can add modern libraries, Argon2id is the best general choice because it offers strong memory hardness and flexibility to tune time and memory separately. If you need wide compatibility or are constrained by a platform (for example some managed services or HSMs), PBKDF2 with a high iteration count is acceptable. If you already use bcrypt and don’t have a pressing need to migrate, it remains a solid option when configured with an appropriate cost setting and combined with other protections like rate limiting and account lockouts. Scrypt can be used if Argon2 is not available but you want memory hardness beyond bcrypt/PBKDF2.
Practical parameter guidance
Parameters should be chosen to make hashing slightly slow on your current hardware while keeping user experience acceptable. That means measuring the wall-clock time of hashing on your expected server hardware, then tuning parameters upward until hashing takes perhaps 100–500 milliseconds per authentication attempt depending on your traffic and latency tolerance. For bcrypt, many teams use a cost of 10–14; pick the highest cost that your servers can handle without impacting throughput. For Argon2id, tune memory first (for example, 64MB–1GB per hash depending on server capacity), set time to 1–3 iterations and parallelism to match available cores; then benchmark. For PBKDF2, increase iterations into the hundreds of thousands if needed to reach your target time. Whatever you choose, record the parameters with each stored hash so you can change defaults later without breaking old passwords.
Implementation and operational tips
Use well-reviewed libraries rather than handcrafted implementations, and avoid exposing hashing load to the public in a way that can be abused (e.g., don’t let attackers trigger large numbers of expensive hashes without mitigation). Always use a unique salt per password , bcrypt and the other functions include salt handling in standard libraries , and consider a site-wide “pepper” (a separate secret stored outside the database) only if you can manage it securely. Keep the hashing parameters and algorithm version alongside the stored hash so you can detect weaker hashes and rehash after successful authentication to an upgraded algorithm. Add standard defensive layers: rate limiting, multi-factor authentication, account lockout thresholds, and logging for suspicious activity.
migrating from one algorithm to another
Switching algorithms is typically done gradually: keep the old hash around and rehash to the new algorithm the next time the user authenticates successfully. Store metadata indicating which algorithm and parameters were used. Avoid bulk rehashing without the user’s password because you can’t extract the cleartext password from a hash. If you need an immediate upgrade for all accounts, consider forcing a password reset or using a background process that prompts users to reauthenticate. Always maintain backward compatibility for verification while you transition.
Summary
For new projects, Argon2id is the best modern choice when available, offering strong memory-hard protections and tunable parameters. Bcrypt remains a viable and familiar option for many systems, but it has limits such as the 72-byte input truncation and weaker memory hardness. PBKDF2 is useful for compatibility and compliance scenarios, while scrypt is an older memory-hard choice when Argon2 is not an option. Whatever algorithm you pick, tune parameters to your hardware, use unique salts, store algorithm/version metadata, and combine hashing with other security controls like rate limiting and multi-factor authentication.
FAQs
Is bcrypt still secure?
Yes, bcrypt is still considered secure when used with an appropriate cost factor and when combined with other protections, but it is not as resistant to modern GPU/ASIC attacks as memory-hard algorithms like Argon2. For new systems, consider Argon2id if possible.
Should I use Argon2 for a new project?
Yes, Argon2id is recommended for new projects because it provides configurable memory hardness and good resistance against parallel hardware attacks. Make sure your environment supports a well-reviewed Argon2 implementation.
How do I choose hashing parameters?
Benchmark hashing on the hardware you will use in production, and choose parameters so a single hash takes an acceptable amount of time for legitimate users (commonly 100–500 ms). Increase memory and time within resource limits to make attacks expensive.
Can I migrate from bcrypt to Argon2 without forcing password resets?
Yes. Keep existing bcrypt hashes and rehash passwords to Argon2 when users successfully log in. Store metadata to know which algorithm to use for verification and rehashing. Forcing resets is only necessary if you require immediate migration for all accounts.
