🧮 Argon2 vs bcrypt vs PBKDF2: Which Password Hashing Algorithm to Use in 2026
When a service stores your password, it should never keep the password itself. Instead it stores a hash: the output of a deliberately expensive function that is easy to compute in one direction and effectively impossible to reverse. The choice of which function to use is one of the most consequential decisions an engineer makes, because it decides how quickly an attacker who steals the database can crack the credentials inside it. In 2026 the practical shortlist comes down to three names: Argon2, bcrypt, and PBKDF2.
This guide explains what separates them, why memory-hardness has become the deciding factor, and which one you should reach for depending on your constraints. If you generate credentials with a tool like SecureKeyGen, understanding what happens to them on the server side completes the picture.
Why Fast Hashing Is the Enemy
General-purpose hash functions such as SHA-256 were designed to be fast. That is exactly what you want for verifying file integrity, and exactly what you do not want for passwords. A modern GPU can compute billions of raw SHA-256 hashes per second, so if a site stored passwords as plain SHA-256, an attacker with a stolen dump could test enormous wordlists almost instantly.
Password hashing functions solve this by adding two defences. First, a unique random salt per user prevents precomputed rainbow tables and ensures identical passwords produce different hashes. Second, a deliberate work factor makes each guess slow. As OWASP puts it in its Password Storage Cheat Sheet, the goal is to make hashing "computationally expensive, while still keeping response times reasonable" — a tuning exercise, not a fixed setting.
The Three Contenders
PBKDF2 — the compliance workhorse
PBKDF2 (Password-Based Key Derivation Function 2) is the oldest of the three, standardised in RFC 8018. It works by applying a pseudorandom function such as HMAC-SHA256 many thousands of times in sequence. Its work factor is the iteration count: raise the count, and each guess costs more.
PBKDF2's strength is also its weakness. It relies only on CPU time, uses very little memory, and is trivially parallelised on GPUs and ASICs. Its enduring advantage is regulatory: PBKDF2 is a NIST-approved, FIPS-140-validated algorithm, which is often mandatory in government and regulated financial systems. NIST SP 800-63B explicitly endorses PBKDF2 with a salt and a "suitably large" iteration count for verifier storage.
bcrypt — the battle-tested default
bcrypt, introduced in 1999 and based on the Blowfish cipher, was the first widely deployed function designed specifically to resist hardware acceleration. Its cost parameter (a power of two, typically 10 to 12) doubles the work with each increment. Because bcrypt's internal state exceeds a typical CPU cache line, it is modestly memory-bound, which made GPU cracking harder than with PBKDF2 for many years.
bcrypt's main limitation is that it truncates inputs beyond 72 bytes and its memory use — around 4 KB — is fixed and small by modern standards. Still, after 25 years of scrutiny, it remains a safe, boring, well-understood choice, and OWASP lists it as an acceptable option where Argon2 is unavailable.
Argon2 — the modern winner
Argon2 won the Password Hashing Competition in 2015 and is the algorithm most security teams now reach for first. It comes in three variants: Argon2d (maximises GPU resistance), Argon2i (resists side-channel attacks), and Argon2id (a hybrid that OWASP and the IETF recommend for password storage). Its defining feature is memory-hardness: it can be configured to require large amounts of RAM per hash, which is expensive to replicate across the thousands of parallel cores on a cracking rig.
Argon2 exposes three tunable parameters — memory cost, time cost (iterations), and parallelism — giving defenders far finer control than a single iteration count. That flexibility is why it has become the default recommendation for new systems.
Side-by-Side Comparison
| Property | PBKDF2 | bcrypt | Argon2id |
|---|---|---|---|
| Year standardised | 2000 (RFC 2898) | 1999 | 2015 |
| Memory-hard | No | Slightly (~4 KB) | Yes (configurable) |
| GPU / ASIC resistance | Low | Moderate | High |
| Tuning knobs | Iterations | Cost factor | Memory, time, parallelism |
| FIPS-140 approved | Yes | No | No |
| Input length limit | None | 72 bytes | None |
| Best for | Compliance-bound systems | Legacy / general use | New applications |
What OWASP and NIST Actually Recommend
The clearest guidance comes from OWASP's Password Storage Cheat Sheet, which sets out a preference order and concrete parameters. Paraphrased, its 2026 recommendations are:
- Argon2id first: a minimum configuration of 19 MiB of memory, an iteration count of 2, and 1 degree of parallelism.
- bcrypt where Argon2 is unavailable: a work factor of 10 or more, with the password pre-hashed if it may exceed 72 bytes.
- PBKDF2 where FIPS compliance is required: 600,000 iterations for PBKDF2-HMAC-SHA256, or 210,000 for SHA-512.
The underlying principle from NIST SP 800-63B is worth quoting directly: verifiers "SHALL store memorized secrets in a form that is resistant to offline attacks," using an approved key derivation function with a salt of at least 32 bits. In plain terms, every standards body agrees on the same thing — never store what you cannot afford to have stolen in the clear, and make each guess costly.
How to Choose in Practice
Answering "which should I use?" comes down to three questions:
- Are you building something new with no compliance constraint? Use Argon2id. It gives the strongest resistance to modern cracking hardware and the most tuning control.
- Do you need FIPS-140 validation? Use PBKDF2-HMAC-SHA256 with at least 600,000 iterations, and revisit the count as hardware improves.
- Are you maintaining a mature system already on bcrypt? Stay on bcrypt at cost 12+ unless you have a specific reason to migrate; a forced rewrite introduces more risk than it removes.
Whichever you choose, the human factor still dominates. No hashing algorithm can save a password that appears in a breach wordlist, because the attacker guesses the common candidates first. That is why length and randomness at creation time matter as much as the hash on the server. Generate long, unique credentials with a client-side tool, store them in a reputable manager such as NordPass, and the server's hashing function becomes your last line of defence rather than your only one.
Why This Matters for You
As a user you rarely get to pick which algorithm a website uses, but you can still act on this knowledge. Favour services that publish their security architecture and mention Argon2 or bcrypt. Treat any site that emails you your existing password as a red flag — it means they can read it, which no correctly hashed system can. And assume every credential you create will eventually sit in a stolen database somewhere; the only question is whether the hash protecting it was designed to slow attackers down for years or crumble in hours.