bcrypt vs Argon2

Passwords should not be stored in a database as plaintext or as ordinary fast cryptographic hashes. If an attacker obtains a database containing password hashes, a fast hash function can allow enormous numbers of password guesses to be tested quickly. Password hashing algorithms are specifically designed to make these attacks more expensive.

bcrypt and Argon2 are two established password hashing algorithms designed for this purpose. Both can be used to protect passwords against offline guessing attacks, but they use different designs and provide different configuration options.

Argon2 is generally the more modern choice for new systems, particularly Argon2id, while bcrypt remains widely deployed and can still provide strong password protection when configured appropriately. The right choice also depends on your platform, available libraries, compatibility requirements, and whether you are migrating an existing password database.

bcrypt vs Argon2 at a Glance

The most important distinction is that Argon2 provides explicit memory-cost and parallelism parameters in addition to a time-related cost. This makes it possible to deliberately consume significant memory during password hashing, which can make large-scale password cracking more expensive.

Why Passwords Need Special Hashing

A cryptographic hash function such as SHA-256 is intentionally very fast. That is useful for many applications, but it is undesirable for password storage because attackers can use powerful hardware to calculate huge numbers of candidate hashes.

Password
    ↓
Password hashing algorithm
    ↓
Password hash + parameters
    ↓
Database

A password hashing algorithm deliberately introduces computational cost and, depending on the algorithm, memory requirements. The objective is not to make legitimate login impossible. It is to make every password guess more expensive for an attacker.

Modern password hashing should also use a unique salt for every password. The salt prevents identical passwords from producing identical stored hashes and makes precomputed lookup attacks much less useful.

What Is bcrypt?

bcrypt is a password hashing function based on the Blowfish cipher's key schedule. It was designed specifically to make password cracking more expensive than using a general-purpose fast hash.

bcrypt includes a configurable cost factor. Increasing the cost increases the amount of work required to calculate a password hash and therefore increases the work required for an attacker to test a password candidate.

$2b$12$......................................................

A bcrypt hash contains information needed to verify the password later, including the bcrypt version, cost parameter, salt, and resulting hash. Applications therefore do not need to store the salt separately when using standard bcrypt encoded hashes.

How bcrypt Cost Works

The bcrypt cost parameter is logarithmic. Increasing the cost by one roughly doubles the amount of computational work required by the key setup portion of the algorithm.

These values describe the relationship between cost settings rather than a fixed number of milliseconds. Actual runtime depends on hardware, implementation, system load, and library behavior.

bcrypt's 72-Byte Password Limitation

One important bcrypt limitation is its handling of long passwords. The traditional bcrypt specification processes at most 72 bytes of password input. Depending on the implementation and input encoding, this can create surprising behavior for long passwords containing multibyte characters.

This does not mean applications should impose a 72-character password limit. Instead, applications using bcrypt should understand the behavior of their specific library and avoid silently truncating passwords in a way that users do not expect.

What Is Argon2?

Argon2 is a password hashing function designed as part of the Password Hashing Competition. It was created with modern password-cracking hardware in mind and provides configurable time, memory, and parallelism parameters.

Argon2 has three variants: Argon2d, Argon2i, and Argon2id. For general password storage, Argon2id is the variant commonly recommended because it combines properties of the other two designs and provides protection against different classes of attacks.

Argon2 Variants

For ordinary application password storage, Argon2id is generally the variant to consider unless a specific security requirement calls for something else.

How Argon2 Parameters Work

Argon2 provides several parameters that control the resource requirements of hashing. The most important are memory cost, time cost, and parallelism.

This configurability is one of Argon2's major advantages. An application can increase memory requirements as hardware becomes more capable, making large-scale parallel password cracking more expensive.

Why Memory-Hard Hashing Matters

Modern attackers can use GPUs, dedicated hardware, and large amounts of parallel computation. Simply increasing CPU work does not necessarily impose the same cost on every type of cracking hardware.

Memory-hard algorithms require substantial memory bandwidth or memory capacity during computation. This can make it more difficult and expensive to run very large numbers of password guesses in parallel.

Argon2 was specifically designed with memory-hard password hashing in mind. bcrypt also has resource costs, but its design does not provide the same flexible memory-cost configuration available in Argon2.

bcrypt vs Argon2: Security Model

Both algorithms are designed for password hashing rather than general-purpose data hashing. Both use salts and configurable work factors, and both can provide strong protection when implemented and configured correctly.

Argon2id has a more modern design and gives developers explicit control over memory usage and parallelism. bcrypt has a long deployment history and a mature ecosystem, but its design predates many of the password-cracking hardware considerations that influenced Argon2.

The algorithm alone does not determine the security of password storage. Weak passwords, missing salts, poor parameter choices, leaked credentials, vulnerable libraries, and insecure account recovery can all undermine an otherwise strong password hashing scheme.

bcrypt vs Argon2: Performance

Password hashing performance should be evaluated differently from ordinary application performance. A password hash that takes almost no time to calculate is not necessarily a good result. Some intentional delay is part of the security design.

At the same time, hashing must not consume so many resources that legitimate users can easily exhaust the server. A registration or login endpoint can become a denial-of-service target if password hashing parameters are excessively expensive.

bcrypt primarily gives you a cost parameter controlling computational work. Argon2 allows you to balance CPU work, memory usage, and parallelism. This gives Argon2 more flexibility when tuning an application for modern infrastructure.

Memory Usage Comparison

bcrypt is comparatively lightweight in memory usage. This is one reason it remains practical on systems where memory is constrained or where compatibility with existing infrastructure is important.

Argon2 can deliberately use much more memory. That is useful for password security, but it also means configuration must account for the server's available resources.

If an application processes many password hashes concurrently, the configured memory cost can multiply across concurrent operations. For example, a configuration requiring 64 MiB per hashing operation can require hundreds of megabytes if several operations run simultaneously.

CPU Cost vs Memory Cost

bcrypt primarily increases the computational cost of each password guess. Argon2 lets you increase computational work while also requiring substantial memory.

This distinction matters because attackers can parallelize password guesses. A memory requirement can become a limiting resource when an attacker attempts to run many guesses simultaneously.

The goal is not to maximize every parameter. The goal is to find a configuration that creates an appropriate cost for attackers while remaining reliable for legitimate authentication traffic.

How to Choose Argon2 Parameters

Argon2 parameters should be selected through benchmarking rather than copied blindly from an example. Measure password hashing on production-like hardware and consider the maximum expected authentication concurrency.

A practical tuning process is to choose a memory requirement that your infrastructure can comfortably support, select a time cost that produces an appropriate verification duration, and then configure parallelism according to the application's hardware and workload.

Argon2id parameters:

memory cost
time cost
parallelism
salt
output length

The exact values should be treated as deployment configuration rather than universal constants. Hardware changes over time, so password hashing parameters should be reviewed periodically.

How to Choose a bcrypt Cost

The same benchmarking principle applies to bcrypt. Pick a cost that makes password verification intentionally expensive but still practical for legitimate users and expected server load.

A cost value that is appropriate on one machine can be too expensive or too cheap on another. Authentication endpoints also need protection against excessive concurrent hashing attempts.

Salt Is Required for Both

A salt is a unique random value combined with the password during hashing. It prevents two users with the same password from automatically receiving the same stored hash.

password + unique salt
        ↓
password hashing algorithm
        ↓
stored password hash

Modern bcrypt and Argon2 implementations normally generate and encode the salt as part of the password hash representation. Developers should use well-maintained password hashing libraries rather than implementing the algorithms themselves.

Hashing Is Not Encryption

Password hashing is intentionally one-way. An application does not decrypt a stored password hash when the user logs in. Instead, it hashes the submitted password using the parameters and salt stored with the original hash and compares the result.

Encryption is different because encrypted data is intended to be recovered using a key. Passwords normally should not be recoverable by the application, which is why password hashing is appropriate for password storage.

Never Use SHA-256 as a Password Hash by Itself

SHA-256 is an excellent cryptographic hash function, but it is designed to be fast. That makes it inappropriate as the sole password hashing algorithm.

Not recommended for passwords:

SHA-256(password)

Prefer a password hashing algorithm:

Argon2id(password, salt, parameters)
bcrypt(password, cost)

Fast hashes can still be useful for many other tasks, such as integrity checking or content fingerprints. The problem is using a fast general-purpose hash as a password storage mechanism.

bcrypt vs Argon2 in Web Applications

Both algorithms can be integrated into web applications through established libraries. The typical workflow is to hash the password during registration or password change and verify it during login.

Registration:
user password
    ↓
hash password
    ↓
store encoded password hash

Login:
submitted password
    ↓
verify against stored hash
    ↓
allow or reject authentication

The database should store the encoded password hash, not the original password. The application should never need to retrieve the plaintext password from the database.

Use Password Hashing Libraries

Password hashing algorithms are cryptographic primitives and should not be implemented from scratch in application code. Use established libraries that correctly implement the algorithm, salt generation, parameter encoding, and verification process.

A library also reduces the risk of subtle mistakes involving encoding, salt generation, comparison, algorithm versions, and malformed stored hashes.

Password Verification Must Be Safe

Password verification should be performed using the verification function provided by the password hashing library. Do not manually extract the hash and compare strings using application-specific logic.

The verification function understands the encoded hash format, extracts the salt and parameters, performs the appropriate computation, and compares the result correctly.

Hash Storage Format Matters

A password hash should generally be stored in the encoded format produced by the library. This representation contains the information needed to perform future verification.

Stored value:

$algorithm$parameters$salt$hash

The exact format differs between algorithms. Do not assume that bcrypt and Argon2 hashes can be interpreted using the same parser or verification function.

Migrating from bcrypt to Argon2

An existing application does not necessarily need to force every user to reset their password when migrating from bcrypt to Argon2. A common migration strategy is to recognize the existing bcrypt hash at login, verify the supplied password against it, and then replace the stored hash with a new Argon2id hash after successful authentication.

This allows migration to happen gradually as users log in. Accounts that never authenticate may remain on the old algorithm until a password reset or another migration event occurs.

Login:
stored hash is bcrypt
        ↓
verify password
        ↓
authentication succeeds
        ↓
create new Argon2id hash
        ↓
replace stored hash

The migration logic should be carefully tested because authentication failures, malformed hashes, and concurrent password changes need to be handled correctly.

Should You Choose bcrypt for a New Project?

bcrypt can still be a reasonable choice when a platform has strong bcrypt support, an existing ecosystem depends on it, or operational constraints make its simpler resource profile useful.

However, for a new application without compatibility requirements, Argon2id is generally the more modern password hashing option. Its memory-hard design and configurable memory and parallelism parameters provide additional flexibility against modern password-cracking hardware.

When bcrypt Makes Sense

• You are maintaining an existing application that already uses bcrypt.
• Your platform has mature and well-tested bcrypt support.
• Compatibility with existing password hashes is important.
• The application's infrastructure has strict memory constraints.
• Your team has established secure bcrypt parameters and migration policies.

Using bcrypt does not automatically make an application insecure. A properly configured bcrypt implementation can still provide strong password protection. The important factors include password quality, unique salts, an appropriate cost, secure libraries, and overall account security.

When Argon2id Makes Sense

• You are designing a new password-storage system.
• You want a modern memory-hard password hashing algorithm.
• You can control and benchmark memory usage.
• You want explicit memory, time, and parallelism parameters.
• Your infrastructure can handle the selected resource requirements.

Argon2id is particularly attractive for new systems because its design gives developers more control over the resources required for each password guess.

Password Strength Still Matters

Choosing Argon2id instead of bcrypt does not compensate for weak passwords. Password hashing protects stored credentials against offline guessing, but a password such as password123 can remain vulnerable even when protected by a strong algorithm.

Applications should encourage long, unique passwords and support password managers. Password generation can also help users create credentials with substantially more entropy than common human-chosen passwords.

Rate Limiting Still Matters

Password hashing protects the database if an attacker obtains password hashes, but it does not replace online authentication controls. Login endpoints should also use rate limiting, account protections, monitoring, and appropriate abuse detection.

A strong password hashing algorithm and online rate limiting defend against different parts of the attack surface. Password hashing primarily increases the cost of offline guessing, while rate limiting restricts repeated online authentication attempts.

Protect Password Reset Flows

Password storage is only one part of account security. A secure password hash can be undermined by a weak password-reset mechanism that allows an attacker to take control of an account without knowing its password.

Password-reset tokens should be generated securely, have appropriate expiration, and be invalidated when used according to the application's security requirements. Recovery mechanisms should be reviewed with the same care as the login flow.

Do Not Log Passwords or Password Hashes

Passwords should never appear in application logs, analytics events, error messages, URLs, or debugging output. Password hashes should also be treated as sensitive credential material because an attacker who obtains them can attempt offline guessing.

Benchmark Password Hashing in Production-Like Conditions

Development laptops are not reliable benchmarks for production password hashing. Containers, virtual machines, serverless functions, shared CPU resources, and production concurrency can significantly change actual behavior.

Benchmark registration and login workloads using hardware and deployment limits similar to production. Measure both individual verification latency and resource usage under concurrent authentication requests.

Password Hashing and Denial-of-Service Risks

Increasing password hashing cost improves resistance to offline attacks, but the same cost is paid by the application's own servers during legitimate authentication. An attacker may exploit this by generating many authentication attempts.

This is why password hashing configuration should be combined with login rate limiting, request throttling, abuse detection, and appropriate infrastructure capacity. The strongest possible hash parameters are not automatically the safest operational configuration.

bcrypt vs Argon2: Practical Decision

This is not a choice between a secure algorithm and an insecure algorithm. Both can be used securely. The more relevant question is which algorithm fits the application's security requirements, infrastructure, compatibility constraints, and operational model.

A Secure Password Storage Checklist

• Use a dedicated password hashing algorithm such as Argon2id or bcrypt.
• Generate a unique cryptographically secure salt for each password.
• Use a well-maintained library instead of implementing the algorithm yourself.
• Benchmark password hashing on production-like hardware.
• Choose parameters based on both security and server capacity.
• Store the complete encoded password hash.
• Use the library's password verification function.
• Never store plaintext passwords.
• Do not use SHA-256 or another fast hash as the password hash by itself.
• Do not log passwords or password hashes.
• Rate-limit authentication attempts.
• Protect password-reset and account-recovery flows.
• Review password hashing parameters periodically.
• Plan gradual migration when changing hashing algorithms.

Frequently Asked Questions

Helpful Security Tools

A Bcrypt Generator can be useful for inspecting bcrypt hashing behavior and experimenting with cost parameters in a development context. A Password Generator can help create strong random passwords, while an Entropy Calculator can illustrate the relative strength of password candidates. A Secure Random Generator is useful when cryptographically secure random values are needed, and a Hash Generator can help compare general-purpose hashing functions with dedicated password hashing algorithms.

Conclusion

bcrypt and Argon2 are both designed specifically for password hashing and are fundamentally different from fast general-purpose hashes such as SHA-256. Both can protect stored passwords when used correctly with unique salts, appropriate parameters, secure libraries, and proper authentication controls.

For new applications, Argon2id is generally the more modern option because it provides configurable memory, time, and parallelism costs. bcrypt remains a practical and widely supported choice, especially for existing applications and environments where compatibility or lower memory usage matters.

Regardless of the algorithm, secure password storage requires more than choosing a hashing function. Strong passwords, safe verification, rate limiting, protected recovery flows, careful logging, secure libraries, and regular parameter reviews all contribute to the overall security of an authentication system.