Choose Argon2id for new systems when your platform supports it and you want the strongest practical resistance to GPU and ASIC cracking. bcrypt is acceptable for legacy code paths, while scrypt is a reasonable fallback when Argon2id is unavailable but memory-hardness is still required.
Why Argon2id is usually the first choice for new password storage
Argon2id is the modern default when you are designing password hashing from scratch. Its key advantage is tunable memory hardness, which makes large-scale guessing more expensive for attackers using parallel hardware. That matters most when you can choose the algorithm rather than preserve compatibility with an existing password database or legacy authentication flow.
For teams deciding between algorithms, the practical question is not whether bcrypt or scrypt are obsolete, but whether the deployment can support a better fit for current cracking economics. A strong password hash should slow offline attackers without making legitimate logins impractical, and Argon2id gives you more flexibility to tune that balance than older, more fixed designs.
How bcrypt and scrypt compare when compatibility matters
bcrypt remains a credible option when an established system already depends on it, especially if the surrounding code and operational processes are stable. Its long history and broad support still make it easy to run safely, but it is less adaptable to modern hardware trends than newer memory-hard designs. In practice, that means it is more often a continuity choice than a greenfield choice.
scrypt is more memory-hard than bcrypt and is often the better fallback when Argon2id is not available in a platform, language runtime, or managed service. The trade-off is that scrypt support is uneven across ecosystems, and its operational tuning can be harder to standardize. Teams should choose it for the strength of the protection model, not because it is automatically simpler to deploy.
What determines the right password hash in production
The right choice depends on platform support, password volume, login latency budgets, and how much control you have over tuning and migration. If you are building a new system and can adopt Argon2id, that should usually be the starting point. If you are maintaining an older stack, the decision often becomes a migration question, because changing the hash function can require staged rehashing and careful handling of dormant accounts.
Hash selection also sits inside broader credential hygiene. Password storage is only one control, but it is a foundational one because a compromise of stored hashes turns into an offline cracking problem. For that reason, the surrounding controls, such as password policy, breach-blocking, and credential monitoring, matter because they reduce the damage if hashes are exposed. NHIMG’s Password Security and Password Manager Guide is a useful companion when teams are aligning hashing choices with password policy and storage practice.
Risk and Threat Considerations
Password hashes are usually tested under breach conditions, not normal login conditions. The main risk is that an attacker who exfiltrates the database can spend unlimited time cracking weak or poorly tuned hashes offline, which makes algorithm choice, cost parameters, and migration discipline directly security relevant.
Failure mechanism: Fast or weakly tuned hashing reduces attacker cost enough that GPU and ASIC cracking becomes economically practical, especially when users reuse passwords or choose predictable ones.
Impact: Stolen hashes can turn into account takeover, lateral access, and broader credential compromise, so the wrong choice increases both breach blast radius and the speed of post-breach exploitation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Password hashing and lifecycle choices directly affect authenticator protection. |
| SI-7 — Software, Firmware, and Information Integrity | Stored credential protection helps preserve integrity after database exposure. | |
| Recommendation — Use strong, tunable password storage and rotate or retire weak hashing paths during migration. Protect credential stores and validate any migration that changes password handling. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Password hashing selection is a cryptographic protection decision for stored secrets. |
| Recommendation — Define approved password-hash standards and enforce them consistently across systems. | ||
| CIS Controls v8 | CIS-5 — Account Management | Credential storage and account lifecycle controls intersect with password-hash migration. |
| Recommendation — Review account and credential handling so legacy hashes can be upgraded safely. | ||
Practitioner Guidance
What to prioritise: Use Argon2id for new builds when your stack supports it, then set memory, time, and parallelism parameters to fit your latency and capacity envelope. Treat bcrypt as a compatibility path, not a preferred destination, and use scrypt when you need a memory-hard fallback that your platform can actually support consistently.
What to verify: Confirm that your login and reset flows can handle phased rehashing, because the best migration path is often opportunistic rehash on successful authentication rather than a disruptive forced reset. Also verify that your chosen parameters are being measured and revisited, since a hash that was strong at launch can become too cheap as hardware improves.
Practitioner takeaway: Prefer the strongest algorithm your environment can reliably operate, but treat password hashing as a living control, not a one-time selection, because migration and tuning matter almost as much as the algorithm name.