Teams should choose a password hashing algorithm by balancing security, performance, and deployment constraints. Bcrypt is widely supported and slow by design, scrypt adds memory hardness, and Argon2 is the modern standard for resisting brute force attacks with tunable CPU and memory cost. Selection should favor current threat models and operational fit.
Choosing a Password Hashing Algorithm
Password hashing is not just about making passwords slow to crack, it is about choosing a scheme that remains resilient as hardware improves and attacker economics change. bcrypt, scrypt, and Argon2 all slow offline guessing, but they differ in how they consume CPU, memory, and deployment complexity.
bcrypt is the longest-established option and is widely supported in libraries and platforms, which makes it a pragmatic choice for older stacks and conservative deployments. Its strength comes from controlled slowness, but it does not offer the same memory-hard resistance that newer designs use to increase attacker cost on specialised hardware.
scrypt adds memory hardness, which is useful because attackers cannot scale brute-force attempts as efficiently when each guess needs substantial memory. That makes scrypt a stronger fit than plain cost-based hashing when the environment can support higher resource usage.
Argon2 is generally the modern reference point because it is designed for tunable CPU and memory cost and for resisting large-scale offline attacks efficiently. In practice, the best choice is the one your platform can implement consistently with current libraries, operational limits, and a threat model that assumes password databases may eventually be stolen.
What These Algorithms Protect Against
The common goal is to make offline password cracking expensive after credential theft. A good password hash does not stop an attacker from stealing a database, but it reduces the number of password guesses they can test per second and increases the cost of recovering usable credentials.
The main security trade-off is that a stronger hash increases work for both defenders and attackers. Too little work leaves passwords cheap to brute-force, while too much work can create login latency, service load, or compatibility problems. The right balance depends on how sensitive the account is, how often users authenticate, and how much compute the system can absorb.
Teams should also remember that hashing strength is only one layer. Password quality, MFA, rate limiting, and breach-resistant authentication controls still matter because even a strong hash cannot save a weak password or a compromised session.
How Teams Should Evaluate Exposure and Fit
The first question is whether your application already uses a vetted library and a configurable work factor, because insecure custom implementations are the fastest way to lose the benefit of any algorithm. The second is whether the application can afford the chosen CPU and memory cost without harming availability or authentication experience.
Legacy systems often stay on bcrypt because the platform supports it reliably and upgrading an auth stack can be more disruptive than the hash migration itself. Newer systems should usually prefer Argon2 when library support, deployment constraints, and interoperability allow it. scrypt sits in the middle when memory hardness is desired and Argon2 is not yet a clean fit.
When deciding, teams should look at password storage in the context of the full authentication design, not as an isolated implementation detail. The hash algorithm should align with the expected value of the account, the probability of database theft, and the organisation’s ability to tune and revisit parameters over time.
Migration and Operational Considerations
Password hashing choices are rarely one-time decisions. Most teams end up migrating from an older scheme to a stronger one gradually, usually by rehashing credentials at next login or by forcing a reset for affected accounts. That makes algorithm selection a lifecycle issue as much as a technical one.
Operationally, the safest approach is to standardise on one approved algorithm for new passwords, document the chosen cost settings, and treat parameter review as part of security maintenance. If you cannot move immediately, the minimum goal is to keep the existing deployment supported, well-monitored, and easy to rehash later.
Teams should also preserve compatibility with password reset, account recovery, and authentication logging workflows, because a stronger hash does not help if surrounding processes are weak or if migration breaks legitimate access paths.
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, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Password hashing protects stored authenticators and credential lifecycle controls. |
| IA-2 — Identification and Authentication (Organizational Users) | Password hash selection supports secure user authentication for protected accounts. | |
| Recommendation — Use strong password hashing settings and manage reauthentication and reset flows with IA-5. Apply IA-2 by pairing authenticated access with robust password storage controls. | ||
| CIS Controls v8 | CIS-5 — Account Management | Password hashing is part of securing account credentials across their lifecycle. |
| Recommendation — Protect account credentials with approved hashing and controlled credential lifecycle handling. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The term sits within password verifier and authentication assurance guidance. |
| Recommendation — Align password verifier choices and reauthentication practices with digital identity guidance. | ||
Practitioner Guidance
Why practitioners should care: The choice is not about brand preference, it is about whether your password storage can withstand real-world offline cracking while remaining operationally sustainable. A modern default usually reduces long-term risk, but only if the application can support it consistently.
What to watch for: Prioritise algorithm choice alongside library quality, tunable parameters, and the cost of rehashing existing credentials. If a platform cannot support secure tuning or future migration, the implementation problem is bigger than the algorithm name.
Practitioner takeaway: Use the strongest algorithm your stack can support correctly, then plan to revisit the settings as hardware, threat models, and platform capabilities evolve.
Related resources from NHI Mgmt Group
- Guide: Password Security and Password Manager Guide
- What is the difference between bcrypt, scrypt, PBKDF2, and Argon2 during migration?
- What is the difference between Argon2, PBKDF2, bcrypt, and scrypt for password storage?
- How should regulated teams decide between shared SaaS and tenant-owned identity platforms?
- How should security teams decide between native ERP controls and a separate governance platform?