Password Hashing Algorithms Compared: Bcrypt vs Scrypt vs Argon2

Overview

If you only need the short version, here it is: for new systems, Argon2 is often the first algorithm to evaluate seriously. Bcrypt remains widely used, battle-tested, and still reasonable in many environments. Scrypt is valuable when memory hardness is a priority, but in many modern application stacks it is less commonly chosen as the default than Argon2.

That summary is useful, but it is not enough to design secure password storage well. Password hashing is not just about the algorithm name. It is about how the function behaves under attack, how tunable it is, how mature the implementation is in your language or identity platform, and whether your team can operate it confidently over time.

At a high level, all three algorithms exist to make offline password cracking expensive. If an attacker gets a copy of your password database, the goal is to slow down each password guess so much that guessing at scale becomes costly and impractical. A strong password hashing design therefore usually includes:

• a dedicated password hashing function rather than a general-purpose fast hash
• a unique salt per password
• tunable cost settings
• careful implementation and constant-time verification where applicable
• a migration path as recommendations evolve

This matters beyond classic login forms. Password hashing still shows up across developer identity workflows, customer portals, admin consoles, legacy applications, and hybrid environments that have not fully moved to passwordless authentication. Even if your broader roadmap includes magic links, passkeys, or other identity verification tools, secure password storage remains part of the defensive baseline. If your team is also working on token-based auth, it can help to pair this topic with our JWT Claims Reference Guide and Best JWT Decoder Tools Compared to keep storage and session concerns aligned.

The core question is not simply Which is best? It is Which is best for this environment, with these operational constraints, and with a realistic upgrade path?

How to compare options

The most useful comparison framework is not brand recognition or popularity. It is whether the algorithm helps you defend against modern cracking strategies while remaining practical for your application and users.

Here are the criteria worth comparing.

1. Resistance to brute-force and offline cracking

The primary job of a password hashing function is to make guessing expensive. Bcrypt does this mainly through CPU cost. Scrypt and Argon2 add memory hardness, which aims to make specialized cracking hardware less efficient by forcing significant memory use per guess.

In practical terms, memory hardness is attractive because attackers do not only use CPUs. They also optimize with GPUs, FPGAs, and custom hardware. A design that demands memory as well as computation can raise attacker costs more effectively than a CPU-only approach.

2. Tunability

You want settings you can adjust over time. Hardware improves. Traffic changes. Your threat model matures. A hashing scheme with good tuning controls lets you raise the cost as your environment evolves.

Bcrypt is tunable through a cost factor. Scrypt exposes several parameters that influence CPU and memory usage. Argon2 offers multiple dials, including memory cost, time cost, and parallelism. That flexibility is powerful, but it also means teams need disciplined configuration rather than copy-pasting arbitrary values.

3. Implementation maturity

The best password hashing algorithm on paper can still be the wrong operational choice if your stack has weak library support, uneven defaults, or hard-to-audit wrappers. For production systems, implementation maturity matters almost as much as the primitive itself.

Ask practical questions:

• Is there a well-maintained library in your language?
• Does your identity provider support the algorithm natively?
• Can your team verify hashes across services during migration?
• Are defaults documented clearly?
• Will future maintainers understand the configuration?

4. Performance under legitimate login traffic

Password hashing should be intentionally expensive, but not so expensive that it creates self-inflicted denial-of-service risk or unacceptable login latency. A good configuration balances user experience, backend capacity, and attack resistance.

This is especially important for multi-tenant cloud identity tools, consumer apps with login spikes, and admin systems exposed to hostile traffic. The right answer is often benchmark-driven rather than theoretical.

5. Migration complexity

Very few teams start from a blank slate. They inherit legacy users, old hashes, mixed environments, and business pressure not to force mass password resets. The easier your migration path, the more likely you are to improve security without service disruption.

In real systems, the best hashing choice is often the one you can deploy safely now, paired with a plan to rehash on login and retire weak legacy formats steadily.

Feature-by-feature breakdown

This section compares bcrypt, scrypt, and Argon2 on the factors that matter most in secure password storage.

Bcrypt

What it is: Bcrypt is a long-standing password hashing function designed to slow down brute-force attacks through an adjustable work factor.

Why teams still use it: Bcrypt has a long operational history, broad language support, and widespread familiarity. Many developers, framework maintainers, and platform teams know how to configure and troubleshoot it. That familiarity lowers adoption friction.

Strengths:

• mature ecosystem and broad support
• simple cost-factor model
• widely understood by developers and auditors
• still a meaningful improvement over outdated or fast hashes

Limitations:

• primarily CPU-hard rather than strongly memory-hard
• less flexible tuning model than newer options
• can be outclassed by newer designs in environments where hardware-assisted cracking is a major concern

Best interpretation: Bcrypt is not obsolete simply because newer algorithms exist. It remains a defensible choice in many systems, especially when implementation reliability and interoperability matter more than adopting the newest recommendation immediately. But for greenfield projects, it should usually be compared against Argon2 rather than selected automatically from habit.

Scrypt

What it is: Scrypt is a password hashing function designed to be both computationally expensive and memory-intensive, making large-scale cracking less efficient on parallel hardware.

Why it matters: Scrypt helped push password hashing toward memory hardness in a more explicit way. That made it influential in the broader shift away from CPU-only cost models.

Strengths:

• memory-hard design raises attacker resource requirements
• tunable parameters for balancing memory and CPU cost
• solid option where memory pressure is part of the threat model

Limitations:

• configuration can be harder for teams to reason about
• less often the default choice in modern application guidance than Argon2
• library support and operational ergonomics may be less straightforward depending on stack

Best interpretation: Scrypt remains a serious algorithm, not an also-ran. But in many current discussions, it sits in an awkward middle ground: stronger in memory-hardness terms than bcrypt, yet often less favored than Argon2 for new deployments when Argon2 is readily available and well supported.

Argon2

What it is: Argon2 is a newer family of password hashing functions designed to resist brute-force attacks with configurable memory cost, time cost, and parallelism. In practice, people often mean Argon2id when discussing modern password storage because it is commonly treated as the balanced variant to evaluate first.

Why teams choose it: Argon2 was built with modern attack realities in mind. Its tunability and memory-hardness make it attractive for new systems that want a more current baseline than bcrypt.

Strengths:

• strong modern design with memory-hard characteristics
• multiple tuning controls for fine-grained configuration
• often the leading candidate for new password hashing deployments

Limitations:

• more knobs can mean more room for poor configuration
• support may vary across older frameworks and managed identity products
• migration from legacy systems still requires careful rollout planning

Best interpretation: If your stack supports it well, Argon2 is often the first option to test for new development. It is not a shortcut to security by itself, but it gives teams a strong foundation when paired with sensible parameters, salts, monitoring, and migration hygiene.

Quick comparison matrix

• Ease of adoption: bcrypt often wins because it is so widely supported.
• Modern memory-hard design: Argon2 and scrypt are stronger candidates than bcrypt.
• Default choice for many new systems: Argon2 is often the first algorithm to assess.
• Legacy compatibility and familiarity: bcrypt usually has the edge.
• Parameter simplicity: bcrypt is easier to explain; Argon2 and scrypt offer more control.

What not to do

A useful comparison also includes anti-patterns. Avoid these common mistakes:

• using fast general-purpose hashes for passwords
• using a single global salt instead of unique per-password salts
• choosing an algorithm and never revisiting cost settings
• assuming framework defaults are always current
• building custom password hashing logic when established libraries exist
• treating password hashing as separate from rate limiting, MFA, and login abuse controls

Password hashing protects stored secrets. It does not replace broader account protection. If you are evaluating alternatives to passwords for some user journeys, our guides on passwordless journeys and attack patterns against OTPs and magic links are useful companion reads.

Best fit by scenario

The right algorithm depends on the shape of the system, not just security ideals.

Scenario 1: New application with full control over the auth stack

If you are building a new application and can choose modern libraries freely, Argon2 is usually the first option to benchmark. This is especially true if your team wants a current approach to secure password storage and can validate implementation support carefully.

Good fit: Argon2
Why: modern design, flexible tuning, strong candidate for greenfield deployments

Scenario 2: Mature platform with existing bcrypt hashes and limited migration appetite

If you already use bcrypt correctly and your main challenge is operational stability, keeping bcrypt while raising cost factors over time may be more realistic than rushing into a full migration. A secure improvement that actually ships is often better than a theoretically ideal migration that stalls for a year.

Good fit: bcrypt, with a planned upgrade path
Why: broad compatibility, predictable operations, easier staged rehashing

Scenario 3: Security-sensitive environment concerned about hardware-accelerated cracking

When memory hardness is a top consideration, scrypt and Argon2 deserve closer attention than bcrypt. In many cases, Argon2 will still be the preferred candidate for modern deployments, but scrypt may remain viable where library support, compliance context, or internal standards already favor it.

Good fit: Argon2 or scrypt
Why: better alignment with memory-hard defense goals

Scenario 4: Framework or identity provider constrains your options

Sometimes the choice is partly made for you. Managed auth services, enterprise IAM stacks, and inherited framework defaults can narrow the field. In that case, the best move is not to fight the platform blindly. Instead, verify whether the provided implementation is sound, tune it responsibly, and document a future migration path if needed.

Good fit: whichever secure option your platform supports well
Why: implementation quality often outweighs theoretical preference

Scenario 5: Mixed legacy migration

If you are moving from older password storage schemes, the migration pattern matters more than the headline algorithm. A common and practical approach is:

1. verify the password against the legacy hash on login
2. if the login succeeds, immediately rehash with the newer algorithm and current parameters
3. store metadata so you know which algorithm and cost each user record uses
4. retire old formats gradually

Good fit: often bcrypt to Argon2, or legacy hash to bcrypt/Argon2 depending on stack
Why: minimizes user friction while steadily improving security

Scenario 6: High-scale login traffic with tight latency targets

In high-volume systems, benchmark first and decide second. The strongest algorithm with an impractical configuration is not the right answer. Measure real login latency, memory impact, queueing behavior, and abuse handling under load. Then pick the strongest setup your system can sustain safely.

Good fit: benchmark-driven choice, often Argon2 or bcrypt depending on constraints
Why: capacity planning is part of security engineering

When to revisit

Password hashing choices should not be frozen indefinitely. This is a decision to review on a schedule and after specific changes. The most useful time to revisit bcrypt vs scrypt vs Argon2 is when one of these triggers appears:

• your framework or identity platform adds stronger native support for a newer algorithm
• you are redesigning login, MFA, or account recovery flows
• you detect rising login abuse or credential stuffing pressure
• your infrastructure changes enough to support higher cost settings
• you inherit another user database with different hash formats
• new platform constraints, compliance expectations, or security reviews force reassessment

For most teams, the practical next step is not an immediate full migration. It is a short review cycle with concrete outputs:

1. Inventory what you use now. Identify algorithms, cost parameters, salt handling, and where each implementation lives.
2. Benchmark with your real stack. Test login latency, memory use, and concurrency under realistic load.
3. Decide on a target state. For many new builds this may mean Argon2; for stable legacy systems it may mean keeping bcrypt with stronger tuning until migration is justified.
4. Version your hash metadata. Store enough information to know how each password was processed and when it should be upgraded.
5. Rehash on successful login. This is often the least disruptive migration pattern.
6. Review annually or after major auth changes. Treat password hashing like any other living security control.

The durable lesson is simple: the best password hashing algorithm is not chosen once and forgotten. It is selected in context, tuned deliberately, and revisited as software support, threat models, and operational realities change. If you want a clean default for modern systems, start with Argon2. If you run a large installed base on bcrypt, improve it methodically rather than apologizing for it. If you need memory-hard alternatives and have a reason to consider scrypt, evaluate it against your implementation and migration realities. Security decisions age. Good identity engineering plans for that.