Argon2id, bcrypt and scrypt: choosing the right password hash

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: Argon2id, bcrypt, and scrypt are compared for password hashing, and Argon2id is the default choice for new systems, with bcrypt and scrypt remaining situational options.

Why it matters: Password hashing is a core identity control, and practitioners need to choose algorithms and parameters that remain resistant to modern cracking hardware without creating usability or migration problems.

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.
• For FIPS-140 environments, PBKDF2 with HMAC-SHA-256 needs an iteration count of at least 600,000.

Context

Password hashing is a one-way transformation that turns a password into a verifier, and the point is to make offline guessing expensive enough that stolen databases are not immediately reusable. The article focuses on the operational tradeoff between speed for legitimate users and resistance to modern cracking hardware, which is the real control question behind algorithm selection.

For IAM teams, the choice sits inside broader authentication design rather than as a standalone cryptography decision. That means cost tuning, input-length handling, and migration strategy matter as much as the algorithm itself, especially when systems need to survive framework upgrades, compliance constraints, or older application code.

WorkOS presents the topic as a practical decision guide rather than a pure cryptography comparison. The throughline is that modern password hashing governance is about keeping the verification path slow enough for attackers, predictable enough for operations, and flexible enough to move when the default changes.

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. bcrypt is acceptable for legacy code paths, while scrypt is a reasonable fallback when Argon2id is unavailable but memory-hardness is still required.

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. If an encrypted vault falls into the wrong hands, the defender wants to force many extra computations before any guess can be tested. That does not stop theft, but it can turn a feasible cracking attempt into an impractical one.

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. That creates unexpected collisions, weakens user intent, and can become dangerous if developers try to pre-hash around the limit without handling encoding carefully.

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.

Technical breakdown

Why fast hashes fail against offline cracking

Password hashes exist to make stolen credentials expensive to test offline. Fast functions such as MD5 or SHA-256 are wrong for this job because attackers can run billions of guesses per second once they have a dump. Good password hashing adds salt, work factor, and deliberately expensive computation so each guess costs real time and memory. The article’s core point is that the relevant comparison is not just algorithm popularity, but how much each design frustrates parallel cracking on GPUs and ASICs. That is why modern password hashing is a governance control, not just a developer convenience.

Practical implication: set password hashing policy around offline attack resistance, not around hashing speed or implementation simplicity.

bcrypt, scrypt and Argon2id use different cost models

bcrypt relies on repeated Blowfish key setup and exposes a single cost factor, which is easy to tune but mostly CPU-bound. scrypt adds memory hardness through a large pseudorandom array and three parameters, N, r, and p, which improves resistance to parallel hardware but makes tuning more complex. Argon2id combines data-independent and data-dependent access patterns, with separate memory, time, and parallelism controls, so it can balance side-channel safety and cracking resistance more explicitly. The article’s practical distinction is that the three algorithms solve the same problem with different attacker costs and operational tradeoffs.

Practical implication: choose the algorithm whose tuning model your platform and operations team can manage safely over time.

Password hash tuning changes the attack surface

The article highlights several implementation traps that change risk materially: bcrypt truncates input at 72 bytes, pre-hashing can create null-byte quirks, and scrypt and Argon2 can be misconfigured if parameters are copied without benchmarking. It also notes that hash strings embed parameters, which is useful for future migration because the system can identify how a stored password was originally processed. This turns password hashing into a lifecycle problem: strong defaults help, but the real control is maintaining the ability to rehash as recommendations and hardware change.

Practical implication: benchmark in your own environment and store algorithm parameters so you can migrate hashes without breaking authentication.

NHI Mgmt Group analysis

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.

Password hashing governance is a lifecycle problem, not a one-time cryptography choice. The article makes clear that cost factors, memory settings, and migration paths matter because hardware and guidance change over time. That means the control objective is not simply to pick a strong hash today, but to preserve the ability to rehash users as defaults move. Teams that freeze their configuration are effectively accepting future downgrade risk by inertia.

Legacy bcrypt usage remains acceptable only when the governance boundary is explicit. The main failure mode is not that bcrypt is unusable, but that organisations keep it without enforcing input-length limits, tuned work factors, and a plan to move when platform support allows. That creates a hidden security debt that often survives far longer than the code that introduced it. Practitioners should treat legacy hash choice as an exception with a documented exit path.

Long-lived password hash settings create a form of security debt that attackers eventually exploit. The article’s strongest operational message is that password hashing strength degrades when organisations fail to revisit cost settings as hardware improves. This is where algorithm choice and governance converge: a secure hash today can become a weak one tomorrow if it is never re-evaluated. The implication is to manage password hashing as a standing control, not a static implementation detail.

FIPS constraints can override cryptographic preference, which makes policy clarity essential. The article notes that FIPS-140 environments may require PBKDF2 with HMAC-SHA-256, even though it lacks the memory-hardness of Argon2id and scrypt. That is a reminder that compliance and security are not always aligned, and teams need to know when the approved control set is narrower than the technically strongest option. The practitioner task is to document where policy, not preference, determines the hash standard.

What this signals

Password hashing is a lifecycle control, not a static implementation choice. The strongest algorithm today is only useful if its parameters are re-evaluated as hardware and guidance change. That makes migration planning, not algorithm branding, the enduring governance issue for authentication teams.

Memory-hardness is the key differentiator between legacy and modern password hashing. bcrypt still protects credentials when tuned correctly, but scrypt and Argon2id better constrain parallel cracking on modern attacker infrastructure. IAM teams should treat that gap as a risk-management decision, not a syntax preference.

For practitioners

• 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.
• Preserve algorithm metadata for future rehashing Store the algorithm and parameter set inside the hash format so you can rehash users on successful login when minimum recommendations change.
• Handle compliance constraints explicitly If a regulated environment requires FIPS-140 alignment, document PBKDF2 with HMAC-SHA-256 and the approved iteration policy separately from your preferred default.

Key takeaways

• Password hashing should be selected for offline attack resistance, not for implementation convenience or raw speed.
• Argon2id is the recommended default for new deployments, while bcrypt and scrypt remain situational choices for legacy or constrained environments.
• Parameter tuning, input-length handling, and rehash migration matter as much as the algorithm itself.

Key terms

• Password Hash: A password hash is a one-way verifier created from a password and a salt so the original secret cannot be recovered from the stored output. In identity systems, the hash must be slow and parameterised so attackers cannot test guesses cheaply after a database leak.
• Memory-Hard Function: A memory-hard function forces an attacker to spend meaningful RAM as well as compute for each password guess. That makes parallel cracking on GPUs and ASICs less efficient and is central to why scrypt and Argon2id are preferred over purely CPU-bound designs.
• Work Factor: A work factor is the configurable cost applied to password hashing so verification takes longer for attackers but remains acceptable for users. In practice, the right work factor is high enough to slow bulk guessing and low enough to avoid making sign-in unusable or unreliable.
• Password Hash Migration: Password hash migration is the process of moving stored credential verifiers from one system to another without forcing users to reset their passwords. The security requirement is not just copying data, but preserving the hashing integrity and authentication behaviour while the platform changes underneath it.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.