Notifications
Clear all
Topic starter
06/06/2026 2:08 am
TL;DR: Password hashing should be slow, salted, and hard to accelerate, but bcrypt, scrypt, and Argon2 make different tradeoffs against modern attack hardware, according to WorkOS. Argon2id is the default for new systems, bcrypt remains a legacy fallback, and the real governance issue is tuning and migration rather than algorithm choice alone.
NHIMG editorial — based on content published by WorkOS: Picking a password hash: A developer's guide to argon2, bcrypt, and scrypt
By the numbers:
- bcrypt has a hard input limit of 72 bytes.
- OWASP recommends scrypt with a minimum CPU/memory cost of N = 2^17, block size r = 8, and parallelism p = 1 when Argon2id isn't available.
- OWASP's current guidance is to use Argon2id as the default, with one of two minimum configurations: m = 19 MiB, t = 2, p = 1, or m = 46 MiB, t = 1, p = 1.
Questions worth separating out
Q: How should security teams choose a password hashing algorithm for modern applications?
A: Start with Argon2id for new systems, use scrypt when Argon2 support is limited, and keep bcrypt only where legacy compatibility or environmental constraints require it.
Q: Why do memory-hard hashes matter for password security?
A: Memory-hard hashes raise the cost of GPU and ASIC cracking by forcing attackers to spend scarce memory as well as compute.
Q: What do organisations get wrong about bcrypt in legacy systems?
A: The common mistake is treating bcrypt as if age alone makes it sufficient.
Practitioner guidance
- Standardise on Argon2id for new password stores Use Argon2id as the default choice for greenfield authentication systems, and set parameters that keep verification in the 250 to 500 ms range on your own servers.
- Retire weak bcrypt assumptions If bcrypt remains in use, enforce a cost factor of at least 12 and reject passwords that exceed the 72-byte limit without a safe encoding strategy.
- Add a separate pepper for high-value credential stores Store the pepper outside the database in a secrets manager or HSM so a database-only breach does not expose everything needed for offline cracking.
What's in the full article
WorkOS's full article covers the implementation detail this post intentionally leaves for the source:
- Parameter tuning guidance for bcrypt, scrypt, and Argon2id across common language libraries.
- Code-level cautions on bcrypt input limits, null-byte edge cases, and safe pre-hashing patterns.
- Practical benchmarking advice for setting verification latency in real deployment environments.
- A concise decision table that maps algorithm choice to legacy, greenfield, and compliance-constrained stacks.
👉 Read WorkOS's comparison of bcrypt, scrypt and Argon2id for password hashing →
Argon2id vs bcrypt vs scrypt: what should teams use now?
Explore further
06/06/2026 3:37 am
Password hashing is a human identity control, not a developer detail. The choice of bcrypt, scrypt, or Argon2id determines how much damage follows a credential database leak, which makes it a core IAM control surface. Because password verification sits upstream of SSO, MFA, and session control, weak hashing weakens the entire authentication chain. Practitioners should treat hash policy as part of identity governance, not application style.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Should organisations use PBKDF2 when FIPS certification is required?
A: Yes, if the certification requirement is real and unavoidable, PBKDF2 with HMAC-SHA-256 is the compliant option. The tradeoff is that it lacks memory-hardness, so the choice should be documented as a compliance-driven exception rather than a preferred security baseline. Governance matters as much as the algorithm itself.
👉 Read our full editorial: Argon2id, bcrypt and scrypt: choosing the right password hash
