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.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Picking a password hash: A developer's guide to argon2, bcrypt, and scrypt”.
By the numbers:
- bcrypt can be tuned so that verification takes around 250 milliseconds on servers.
- OWASP recommends bcrypt with a minimum work factor of 10, and ideally 12 or higher on modern hardware.
- OWASP's current guidance is to use Argon2id as the default, with minimum configurations of m = 19 MiB, t = 2, p = 1 or m = 46 MiB, t = 1, p = 1.
Key questions
Q: When should teams choose Argon2id instead of bcrypt or scrypt?
A: Choose Argon2id for new systems when your platform supports it and you want the strongest practical resistance to GPU and ASIC cracking.
Q: Why does adding more password hashing work reduce the risk of offline attacks?
A: Adding more hashing or derivation work makes each password guess slower and more expensive for an attacker.
Q: What breaks when bcrypt is used without input-length controls?
A: bcrypt truncates passwords at 72 bytes, so longer inputs can be silently reduced to the first 72 bytes.
Practitioner guidance
- Adopt Argon2id for new systems Set Argon2id as the default password hash for greenfield authentication flows and choose parameters that keep verification around 250 to 500 milliseconds on your own servers.
- Tune bcrypt only as a legacy exception If an application already uses bcrypt or cannot support Argon2id or scrypt, set the cost factor to at least 12 and enforce a maximum password length at or below 72 bytes.
- Benchmark hash settings in production-like conditions Measure verification time in your actual environment rather than copying parameters from another stack, because memory limits and container sizing change the effective cost.
Bottom line: Password hashing should be selected for offline attack resistance, not for implementation convenience or raw speed.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 11 hours ago by NHI Mgmt Group
06/06/2026 3:37 am
Argon2id is the clearest modern default because it shifts password hashing from CPU cost to attacker cost asymmetry. bcrypt still works, but its CPU-only design leaves more room for parallel cracking on commodity GPU infrastructure. scrypt improves the situation with memory-hardness, yet Argon2id is the option that best aligns with current guidance and current attack economics. The practitioner takeaway is that new authentication builds should default to the algorithm that most directly raises the cost of offline guessing.
A question worth separating out:
Q: How should security teams decide between security strength and compliance requirements?
A: Use the strongest approved hash that your environment allows, but document exceptions where policy is stricter than cryptographic preference. In FIPS-constrained environments, that may mean PBKDF2 with HMAC-SHA-256 even though it is not memory-hard, so governance needs to make the tradeoff explicit.
👉 Read our full editorial: Argon2id, bcrypt and scrypt: choosing the right password hash
This post was modified 11 hours ago by NHI Mgmt Group