Argon2id, bcrypt and scrypt: choosing the right password hash

At a glance

What this is: This comparison shows why Argon2id is the modern default for password hashing, while bcrypt and scrypt remain situational choices based on stack constraints and hardware resistance.

Why it matters: IAM teams need to treat password hashing as part of identity control design, because weak hashing, poor parameter tuning, and missing migration paths undermine human authentication even when SSO and MFA are in place.

By the numbers:

• 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.
• FIPS-140 requirement, 40 requirement, none of these are your primary option.

👉 Read WorkOS's comparison of bcrypt, scrypt and Argon2id for password hashing

Context

Password hashing is the control that stands between a leaked credential database and immediate offline cracking. For identity security teams, the question is not whether to hash passwords, but whether the chosen algorithm, salt strategy, and cost parameters still make brute-force attack economics unfavorable.

This article is really about governance choices in human identity authentication: how long a password hash should remain resilient, how much memory or CPU an attacker must spend to test guesses, and what happens when legacy codebases make the default decision for you. That makes the topic relevant to IAM programme owners, not just developers.

Key questions

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. The decision should also account for tuning, migration, and operational limits, because a technically sound algorithm can still fail if its parameters are misconfigured or never reviewed.

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. That changes the economics of offline guessing after a breach, which is exactly where password hashes do their work. For IAM teams, memory hardness is a practical control against large-scale credential compromise.

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. In practice, weak cost settings, the 72-byte input cap, and unsafe pre-hashing patterns create avoidable exposure. Legacy compatibility may justify bcrypt, but only with explicit controls and a plan to revisit the configuration over time.

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.

Technical breakdown

Why slow password hashing matters in identity systems

Password hashes are meant to be one-way verifiers, not recoverable secrets. The security goal is to make offline guessing expensive after a database leak, which means salts, tunable cost, and resistance to parallel hardware all matter. Fast hashes like SHA-256 are unsuitable because they are optimised for speed, exactly what attackers want. A practical password hash also needs to encode its own parameters so the system can raise the cost later without breaking existing credentials.

Practical implication: Treat hash selection as an identity control decision, not a coding preference, and preserve parameter metadata for future migration.

bcrypt, scrypt and Argon2id compared

bcrypt is battle-tested and simple, but it is CPU-hard rather than memory-hard and truncates inputs at 72 bytes. scrypt adds memory-hardness, which raises the cost of GPU and ASIC cracking, but its three parameters are easier to misconfigure. Argon2id combines data-independent and data-dependent passes, giving the strongest general-purpose resistance against both side-channel and time-memory tradeoff attacks. Its separate memory, time, and parallelism controls make it the most flexible option for modern infrastructure.

Practical implication: Use Argon2id for greenfield systems, keep scrypt as a fallback where Argon2 support is weak, and reserve bcrypt for legacy compatibility.

Parameter tuning, peppers and migration strategy

A strong algorithm can still be undermined by weak settings. Work factors that are too low make hashes cheap to brute-force, while settings that are too aggressive can exhaust memory or slow authentication beyond acceptable limits. A pepper adds a separate secret outside the database, so a database leak alone does not give attackers everything needed to crack hashes. Migration matters too, because hash standards and recommended minimums change as hardware improves.

Practical implication: Benchmark hash verification in your own environment, add a pepper where operationally feasible, and plan rehashing on successful login.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Legacy bcrypt configurations create latent credential exposure risk. bcrypt remains acceptable in constrained or legacy environments, but its 72-byte input limit and CPU-only cost model leave avoidable gaps. That limitation matters when organisations allow long passphrases or rely on hardware that attackers can parallelise aggressively. The implication is clear: a bcrypt deployment with outdated cost settings is not merely dated, it is an identity risk surface waiting for a leak.

Argon2id defines the modern password-hashing baseline for new systems. Its memory, time, and parallelism controls are a better fit for current attack economics than algorithms tuned for older hardware assumptions. Identity verifier hardening: the real governance problem is not choosing any hash, but aligning the verifier with the attacker's cost curve. Security teams should treat Argon2id as the default design assumption for new IAM programmes.

Hash migration is a lifecycle issue, not a one-time implementation task. Password policies age as hardware gets faster and recommendations change. If organisations do not keep a path to rehash on next login, they freeze old security decisions into future identity risk. The practitioner conclusion is that password hashing needs lifecycle ownership, review cadence, and an explicit upgrade path.

FIPS constraints reshape the decision, but they do not remove it. When certification requirements force PBKDF2, teams are choosing compliance compatibility over memory-hard resistance. That tradeoff should be documented as an exception, not treated as equivalence. Identity leaders should know where certification requirements override cryptographic preference and accept the residual risk deliberately.

From our research:

• 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.
• For the broader lifecycle view, see Ultimate Guide to NHIs for how identity controls degrade when ownership and rotation are not maintained.

What this signals

Password hashing is now a governance issue as much as a cryptographic one: when identity teams allow old cost factors to persist, they inherit a larger blast radius if a credential store is ever exposed. The practical response is to align password hashing policy with IAM lifecycle review, not leave it inside application maintenance cycles.

With 80% of identity breaches involving compromised non-human identities such as service accounts and API keys, per the Ultimate Guide to NHIs, identity programmes are already living with the consequences of weak secret handling. That pressure makes strong verifier design part of the same control conversation as secrets rotation and offboarding.

Identity verifier hardening: teams should expect hashing recommendations to evolve, just as credential rotation guidance does. The longer a password store remains untouched, the more likely it is to embed a decision that no longer matches current attack economics or infrastructure reality.

For practitioners

• 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.
• Build a rehash-on-login migration path Preserve algorithm and parameter metadata in the hash string so users can be rehashed during successful authentication as standards evolve.
• Benchmark in your production-like environment Measure verification cost on the same class of compute, memory, and container limits that the application will actually use before you set policy.

Key takeaways

• Password hashing choices directly affect how much damage follows a credential leak, which makes algorithm selection an IAM governance decision.
• Argon2id is the modern default, bcrypt is a legacy fallback, and scrypt sits between them when platform support or constraints require it.
• Benchmarks, rehash-on-login, and separate secret storage are the controls that keep password hashing aligned with current attack conditions.

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 Hashing: Memory-hard hashing is a design that forces attackers to spend significant RAM as well as compute when testing password guesses. This reduces the advantage of GPUs and ASICs, which are efficient at parallel work but less efficient when memory becomes the limiting factor.
• Pepper: A pepper is a secret value added to passwords before hashing, but stored separately from the database. If the database is stolen without the pepper, offline cracking becomes far harder because the attacker does not have all the inputs needed to test guesses.
• Rehash On Login: Rehash on login is a migration pattern that upgrades a user’s stored password hash after a successful authentication using the plaintext password briefly available at that moment. It lets organisations raise work factors or switch algorithms without forcing an immediate password reset.

Deepen your knowledge

Password hashing policy and credential storage governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control baseline for human identity authentication, it is a useful place to start.

This post draws on content published by WorkOS: Picking a password hash: A developer's guide to argon2, bcrypt, and scrypt. Read the original.