BLOG
bcrypt vs Argon2 vs scrypt: Which Password Hashing Algorithm Should You Use?
Every few months, another breach dumps millions of password hashes onto the internet. The hashes cracked within hours were stored with MD5 or SHA-256. The ones that remain uncracked months later were hashed with bcrypt, scrypt, or Argon2. The algorithm you choose determines whether a leaked database is a minor inconvenience or a catastrophic exposure of your users' passwords. So which one should you pick?
TL;DR — Quick Comparison
| Feature | bcrypt | Argon2 | scrypt | Winner |
|---|---|---|---|---|
| Year introduced | 1999 | 2015 | 2009 | — |
| Memory hardness | No (fixed 4 KB) | Yes (configurable) | Yes (configurable) | Argon2 / scrypt |
| GPU/ASIC resistance | Moderate | Strong | Strong | Argon2 |
| Side-channel resistance | Limited | Argon2id variant | Vulnerable | Argon2 |
| Tunable parameters | Cost factor only | Time, memory, parallelism | CPU, memory, parallelism | Argon2 |
| Max password length | 72 bytes | Unlimited | Unlimited | Argon2 / scrypt |
| Library availability | Everywhere | Growing fast | Good | bcrypt |
| OWASP recommendation | Acceptable | Preferred (Argon2id) | Acceptable | Argon2 |
What Is bcrypt?
bcrypt was designed by Niels Provos and David Mazieres in 1999, based on the Blowfish cipher. Its key innovation was the concept of a "cost factor" — a configurable parameter that makes hashing exponentially slower as computing power increases. At cost 10, a single hash takes roughly 100 ms. At cost 12, it takes about 300-400 ms. This adaptive slowness is what makes brute-force attacks impractical.
bcrypt has been battle-tested for over 25 years with no practical attacks discovered against it. That track record matters. The main limitation: bcrypt only uses about 4 KB of memory, which means attackers with GPU farms can parallelize attacks more easily than with memory-hard algorithms. It also silently truncates passwords at 72 bytes — anything after that is ignored.
What Is Argon2?
Argon2 won the Password Hashing Competition in 2015, a multi-year academic contest specifically designed to find bcrypt's successor. It comes in three variants: Argon2d (maximizes GPU resistance), Argon2i (resists side-channel attacks), and Argon2id (combines both, and is the recommended variant). Argon2 gives you three knobs to turn: time cost (iterations), memory cost (how much RAM to use), and parallelism (how many threads). This three-dimensional tunability means you can configure Argon2 to use 64 MB of RAM per hash, making it extremely expensive for attackers to parallelize on GPUs.
The OWASP Password Storage Cheat Sheet currently recommends Argon2id as the first choice for new applications.
What Is scrypt?
Colin Percival designed scrypt in 2009 as a memory-hard key derivation function. Before scrypt, password hashing algorithms were primarily CPU-bound, which meant attackers could throw cheap GPU clusters at the problem. scrypt changed the game by requiring a configurable amount of memory for each hash computation. An attacker would need not just processing power but also large amounts of RAM — a much more expensive resource to scale.
scrypt is well-respected and widely used (it is the basis of Litecoin's mining algorithm), but it has a known weakness: in its standard form, it is not resistant to side-channel attacks. If an attacker can observe cache timing patterns, they can potentially extract information about the hash computation.
Side-by-Side Comparison
Security Against GPU Attacks
bcrypt uses only 4 KB of memory per hash, which fits comfortably in a GPU's fast memory. Modern GPUs can compute billions of SHA-256 hashes per second, but bcrypt's Blowfish-based design slows them down to thousands per second per core — still, the lack of memory hardness leaves room for attackers with large GPU farms. Argon2 and scrypt both require significant memory per hash (configurable from kilobytes to gigabytes), making GPU parallelization far more expensive. Argon2id edges ahead because it combines memory hardness with resistance to timing attacks.
Configuration Flexibility
bcrypt has one parameter: the cost factor. Simple to understand, but limited. scrypt has three: CPU/memory cost (N), block size (r), and parallelism (p), though the interaction between N and r can be confusing. Argon2 also has three parameters — time cost, memory cost, and parallelism — but they are orthogonal and easier to reason about independently. When you want precise control over how much your hash costs in time and memory, Argon2 is the most intuitive to configure.
Ecosystem and Library Support
bcrypt has been around for 27 years. Every major language and framework has a well-tested bcrypt implementation. Node.js has bcryptjs and bcrypt. Python has bcrypt. Go, Java, Ruby, PHP — all covered. Argon2 support has grown rapidly since 2020: argon2-cffi for Python, argon2 for Node.js, native support in PHP 7.2+. scrypt is well-supported too, though its library ecosystem is smaller than bcrypt's.
The 72-Byte Problem
bcrypt silently truncates input at 72 bytes. If your users have passwords longer than 72 characters (rare but possible with passphrase-based authentication), everything after byte 72 is ignored. Two passwords that share the first 72 bytes would produce identical hashes. Argon2 and scrypt have no such limitation. A common workaround for bcrypt is to pre-hash the password with SHA-256, but this introduces additional complexity and potential implementation errors.
Performance Overhead
On a typical web server, you want each password hash to take 200-500 ms — slow enough to frustrate brute-force attacks, fast enough to not annoy users during login. All three algorithms can be tuned to hit this range. bcrypt achieves it with a single cost parameter. Argon2 and scrypt can additionally consume significant memory per request, which means you need to account for memory usage when handling concurrent login requests. On a server handling 100 simultaneous logins with Argon2 configured at 64 MB per hash, that is 6.4 GB of RAM just for hashing.
When to Use bcrypt
Legacy Systems
If your application already uses bcrypt and the cost factor is at 12 or higher, there is no urgent reason to migrate. bcrypt with a high cost factor remains secure against practical attacks. Migration introduces risk and testing overhead that may not be justified.
Simple Applications
For a small project where you want password hashing that just works without tuning memory parameters, bcrypt's single cost factor is easier to configure correctly. One number, one decision. Use the bcrypt Generator to test different cost factors and see how they affect hashing time.
Constrained Environments
On memory-limited devices or shared hosting where you cannot allocate 64 MB per hash operation, bcrypt's fixed 4 KB memory usage is actually an advantage. It works reliably even on the cheapest cloud instances.
When to Use Argon2
New Projects
If you are starting from scratch, Argon2id is the right default. It offers the best combination of GPU resistance, side-channel protection, and configurability. OWASP recommends it. The Password Hashing Competition selected it. Library support is mature enough for production use in every major language.
High-Security Applications
Banking, healthcare, government — anywhere the consequences of a breach are severe, Argon2id's memory hardness provides the strongest defense against well-funded attackers with custom hardware.
Applications with Long Passwords
If your authentication system encourages passphrases or supports very long passwords, Argon2 handles them natively without the 72-byte truncation issue.
When to Use scrypt
When Argon2 Is Not Available
Some environments — particularly older systems or embedded devices — have scrypt implementations but not Argon2. In that case, scrypt is the next best option. It provides memory hardness that bcrypt lacks.
Cryptocurrency and Key Derivation
scrypt is widely used in cryptocurrency mining and key derivation for disk encryption. If you are working in those domains, scrypt is the established standard with extensive tooling and documentation.
When Side-Channel Attacks Are Not a Threat
scrypt's side-channel vulnerability matters when attackers have physical or virtual access to the machine performing the hashing. If your hashing happens on servers in a controlled environment (not shared hosting), this risk is minimal.
Can You Use Multiple Algorithms?
Yes, and many systems do during migrations. A common pattern: store the algorithm identifier alongside the hash (bcrypt hashes already include this as a prefix). When users log in, verify with the stored algorithm and rehash with Argon2id if the current hash uses an older algorithm. Over time, all active users migrate automatically. Users who never log in again keep their old hashes, which remain secure.
Free Tools for Password Hashing
- bcrypt Generator — generate and verify bcrypt hashes with configurable cost factor
- Hash Generator — compute MD5, SHA-1, SHA-256, and other hash types for comparison
- Password Generator — create strong random passwords that resist all hashing attacks
- Encryption Tool — encrypt data with AES and other symmetric algorithms
- Text to Binary — examine the binary representation of password strings
- Base64 Encoder/Decoder — encode hashes for safe storage and transmission
Frequently Asked Questions
Is bcrypt still safe to use in 2026?
Yes, with a cost factor of 12 or higher. bcrypt has no known practical attacks after 27 years of scrutiny. It is not the most future-proof choice for new projects, but existing bcrypt implementations do not need emergency migration.
What does "memory-hard" actually mean?
A memory-hard function requires a significant amount of RAM to compute. Attackers using GPUs or ASICs cannot simply buy more processing power — they also need proportionally more memory, which is physically larger, more expensive, and harder to scale. This makes brute-force attacks orders of magnitude more costly.
What cost factor should I use for bcrypt?
Start at 12 and measure the time on your production hardware. You want each hash to take 200-500 ms. If 12 is too fast on your server, increase to 13 or 14. The cost doubles with each increment, so cost 12 takes about twice as long as cost 11.
Should I pre-hash passwords before bcrypt?
It is a common recommendation to hash with SHA-256 first, then bcrypt the result. This bypasses the 72-byte limit and normalizes Unicode edge cases. The downside: if you do it wrong (e.g., passing a raw binary hash that starts with a null byte), you can weaken the final hash. If you choose this approach, Base64-encode the SHA-256 output before passing it to bcrypt.
How often should I rehash stored passwords?
Rehash on login whenever your current parameters are stronger than the stored hash's parameters. This is the standard approach for gradual migration: store the algorithm and parameters alongside the hash, check on each login, and rehash if the stored parameters are weaker than your current policy.
Make the Call
For new projects: use Argon2id. For existing bcrypt installations: keep it, increase the cost factor if it is below 12, and plan a gradual migration when it makes sense. For environments without Argon2 support: use scrypt. And regardless of the algorithm, generate strong passwords — no hashing algorithm can protect "password123." Generate one with the Password Generator and test your hashes with the bcrypt Generator.