Argon2 and scrypt are memory hard designs that make parallel cracking more expensive by using significant RAM as well as CPU. PBKDF2 and bcrypt are adaptive functions that slow hashing mainly through repeated computation. In practice, memory hard designs offer stronger resistance to modern attack hardware, while PBKDF2 often remains the compatibility driven fallback.
Why This Matters for Security Teams
Password storage is not just a backend implementation choice, it is a resistance decision against offline cracking. If an attacker steals a password hash database, the cost of recovery depends heavily on the algorithm, the cost parameters, and the hardware the attacker can bring to bear. Modern guidance generally favours memory hard schemes such as Argon2 or scrypt when they are available, because they make GPU and ASIC based cracking less efficient than CPU-bound schemes.
PBKDF2 and bcrypt still have a place because they are widely supported and easy to deploy consistently, but they protect mostly by increasing computation, not by forcing the attacker to spend scarce memory. That difference matters most when password quality is poor, breaches are inevitable, and attackers can test vast numbers of guesses offline. Current practice is to treat the password hasher as one layer in a broader authentication posture, not as a substitute for strong password policy or phishing resistant login. In practice, many security teams discover weak hash choices only after a database dump has already been monetised.
How It Works in Practice
These algorithms all slow password guessing, but they do it in different ways, and that changes the attacker’s economics.
- Argon2 is the most modern option of the four. It is designed to be memory hard, so each guess requires meaningful RAM as well as CPU. That reduces the value of highly parallel cracking rigs.
- scrypt is also memory hard. It was built to make large scale parallel guessing more expensive by tying each attempt to a substantial memory footprint.
- bcrypt is an adaptive password hashing function. Security improves by raising the work factor, which increases the number of computation rounds. It remains common because it is mature and broadly implemented.
- PBKDF2 is another adaptive function that increases cost through repeated hashing. It is often retained for compatibility, especially where platforms or compliance baselines lag behind newer choices.
In practical deployment, the key question is not only which algorithm you choose, but whether the parameter values are still meaningful for current hardware. A hash function with a low cost setting can become easy to brute force even if the algorithm itself is sound. Salts are also essential, because they prevent identical passwords from producing identical stored hashes and block precomputed rainbow table attacks. For new systems, Argon2 is usually the preferred default where library and platform support exists; scrypt is the closest alternative when memory hardness is needed but Argon2 is unavailable. PBKDF2 and bcrypt are acceptable when interoperability or legacy constraints force them, provided the iteration or cost settings are reviewed regularly and kept high enough to remain expensive for attackers. NIST SP 800-63 Digital Identity Guidelines is useful here because it frames password storage as part of broader authenticator strength and assurance, not as a standalone checkbox.
These controls tend to break down when teams inherit old defaults, copy parameters from sample code, or assume a single “good” setting will stay adequate across several years of hardware change.
Common Variations and Edge Cases
Tighter password hashing often increases CPU and memory cost for legitimate logins, so organisations have to balance account security against authentication latency and infrastructure load. The right choice also depends on deployment context, because what is acceptable for a consumer web app may be too expensive for a high-volume internal service.
There is no universal standard that says one algorithm is always best in every environment. Argon2 is generally the strongest technical choice, but older application stacks, managed identity products, and compliance-driven platforms may still require PBKDF2 or bcrypt. In those cases, the practical answer is to maximise the cost factor you can support, monitor login performance, and plan a migration path rather than freezing the legacy setting indefinitely. Another edge case is password reuse: a stronger hash does not prevent credential stuffing if users reuse passwords across services, so storage strength must be paired with detection and rate limiting at the authentication layer.
Memory hard designs are especially valuable when attackers are expected to have access to modern GPU hardware, but they can be harder to tune in constrained environments where RAM is scarce or shared. OWASP API Security Top 10 is not a password hashing standard, but it reinforces the broader point that authentication weaknesses become more dangerous when exposed through high-volume interfaces and automation paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | 5.1.1.2 — Memorized Secret Verifiers | Covers secure storage and verifier resistance for passwords. |
| Recommendation — Use a strong password hashing scheme with unique salts and tunable work factors. | ||
| CIS Controls v8 | 5 — Account Management | Password storage choices directly affect account credential protection and recovery. |
| Recommendation — Protect stored credentials with modern adaptive hashing and review parameters regularly. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Covers credential storage practices relevant to password-derived secrets and hashes. |
| Recommendation — Harden credential storage and avoid long-lived, weakly protected secret material. | ||
Practitioner Guidance
Decision rule: If your platform supports Argon2 with sane parameters, use it for new password storage designs. If it does not, choose scrypt next, then bcrypt or PBKDF2 only when platform constraints force that choice. The deciding factor is not algorithm popularity, it is whether the stored hash remains expensive to crack against current attacker hardware.
What to verify: Confirm that salts are unique per password, that the work factor or memory setting is explicitly configured, and that the chosen parameters are still reviewed after major infrastructure changes. Also verify that the application can handle the performance cost without silently lowering settings to preserve login speed.
Common mistake: Teams often treat password hashing as “done” once the library is selected. In reality, a weak parameter choice can erase most of the benefit, and a strong hash cannot compensate for reused passwords, leaked reset flows, or weak account recovery controls.
Practitioner takeaway: The best password storage scheme is the one that remains costly for attackers and operationally maintainable for defenders, with Argon2 usually offering the strongest balance when adoption constraints do not block it.
Related resources from NHI Mgmt Group
- What is the difference between bcrypt, scrypt, PBKDF2, and Argon2 during migration?
- What is the difference between password storage and PAM?
- What is the difference between zero-knowledge password management and standard vault-based password storage?
- What is the difference between zero-knowledge security architecture and traditional password storage models?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 15, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
