Every password stored anywhere eventually runs through a key derivation function, and in 2026 that function is almost always either PBKDF2 or Argon2. Both turn a human-memorable password into a cryptographic key an attacker cannot easily reverse. Both are free, open, and battle-tested. But they were built two decades apart, they solve the GPU-cracking problem in opposite ways, and picking the wrong one still shows up in breach reports today.

PBKDF2 dates back to RFC 2898 in 2000 and leans entirely on raw computation: run HMAC over and over until it’s slow enough to hurt an attacker. Argon2 won the Password Hashing Competition in 2015 and takes a different approach, forcing every guess to allocate a chunk of memory an attacker’s GPU cannot cheaply parallelize. That single design choice is why security teams keep re-litigating this comparison, and why OWASP’s own guidance treats the two algorithms so differently depending on whether an organization needs FIPS 140 compliance or just wants the strongest practical defense.

This piece works through the actual numbers: OWASP’s current recommended parameters, GPU cracking benchmarks pulled from three separate sources, what cloud GPU rental actually costs an attacker per hour, and where PBKDF2 and Argon2 show up in real products today, including a well-documented case where the wrong iteration count contributed to a major breach.

Neither algorithm is going to disappear in the next few years. That’s actually the point of this comparison: most engineering teams aren’t choosing a hash function once and forgetting about it, they’re choosing one now and then living with a migration decision later. Understanding exactly where each algorithm is strong, where it’s weak, and which real products already made the switch gives a much clearer picture than a simple “Argon2 is newer, use that” recommendation would.

What Is PBKDF2? The Original NIST-Approved Key Derivation Function

PBKDF2 (Password-Based Key Derivation Function 2) takes a password, a salt, and an iteration count, then runs a pseudorandom function, almost always HMAC-SHA256 today, that many times in a row. Each additional iteration adds a fixed amount of CPU work to both a legitimate login and an attacker’s guess. There is no memory component at all: PBKDF2 needs only a few kilobytes of RAM regardless of how many iterations it runs, which is exactly the property that makes it cheap to accelerate on a GPU.

That design is also PBKDF2’s biggest strength in regulated environments. It’s standardized in NIST SP 800-132 and is the only one of the two algorithms available in FIPS 140-3 validated cryptographic modules. The OWASP Password Storage Cheat Sheet puts it plainly: “If FIPS-140 compliance is required, use PBKDF2 with a work factor of 600,000 or more and set with an internal hash function of HMAC-SHA-256.” That’s a real jump from OWASP’s earlier 310,000-iteration figure, and it reflects how much cheaper GPU compute has gotten since the last round of guidance.

PBKDF2 also comes in HMAC-SHA512 and legacy HMAC-SHA1 variants. OWASP’s current cheat sheet recommends 220,000 iterations for PBKDF2-HMAC-SHA512, and 1,400,000 iterations for PBKDF2-HMAC-SHA1, the latter marked explicitly as legacy-only. At 600,000 iterations of HMAC-SHA256, a typical server CPU takes roughly 200 milliseconds to hash one password, a number small enough that a real login never notices it but large enough to meaningfully slow a brute-force run.

None of that changes how PBKDF2 handles salting, which is where a lot of real-world weaknesses actually creep in. The algorithm itself doesn’t generate a salt, it just accepts one as an input parameter, so it’s entirely up to the implementer to generate a long, random, unique salt per password and store it alongside the hash. Skip that step, or reuse a salt across users, and even a correctly configured 600,000-iteration PBKDF2 hash becomes trivially easier to attack in bulk, because an attacker can share precomputation work across every account that shares a salt.

What Is Argon2? Inside the Memory-Hard Password Hasher

Argon2 won the Password Hashing Competition in 2015, a multi-year, open cryptographic contest specifically organized to find PBKDF2’s and bcrypt’s successor. It ships in three variants: Argon2d, which is fastest and resists GPU cracking hardest but is vulnerable to side-channel timing attacks; Argon2i, which is side-channel resistant but weaker against GPU attacks; and Argon2id, a hybrid that combines both properties and is the variant every current guide, including OWASP’s, recommends for password storage. The algorithm was later formalized in RFC 9106 in 2021, giving implementers a standard reference for parameter selection instead of guessing.

The core idea is memory-hardness. Argon2 takes three tunable parameters: memory cost (how many kilobytes of RAM each hash requires), time cost (how many passes over that memory), and parallelism (how many independent lanes run at once). Forcing every single guess to allocate real memory is what breaks the GPU’s advantage. A modern GPU can run tens of thousands of parallel SHA-256 computations because each one needs almost no memory, just a small amount of register and cache space. It cannot run tens of thousands of parallel Argon2id computations because it would run out of VRAM long before it ran out of compute cores.

The verified OWASP minimum configuration is Argon2id with 19 MiB of memory, an iteration count of 2, and a parallelism degree of 1. The cheat sheet lists several tuned alternatives depending on how much latency an application can absorb: m=47104 KiB (46 MiB) at t=1, m=19456 KiB (19 MiB) at t=2, m=12288 KiB (12 MiB) at t=3, m=9216 KiB (9 MiB) at t=4, and m=7168 KiB (7 MiB) at t=5, all with parallelism set to 1. Every one of those profiles was built around a simple constraint: force real RAM allocation without pushing login latency past what a user will tolerate.

Parallelism is the parameter people misunderstand most often. It doesn’t multiply the memory cost automatically, a p=4 setting still uses the configured memory total, just split into four lanes that can run concurrently on a multi-core CPU. Raising parallelism speeds up hashing for the legitimate server without meaningfully helping an attacker, since a GPU already runs thousands of parallel threads regardless of what a single Argon2id call requests. That’s part of why OWASP’s own minimum profile keeps parallelism at 1: the memory cost is doing almost all of the defensive work, not the thread count.

PBKDF2 vs Argon2: Full Specs Comparison

The table below lines up both algorithms across the criteria that actually matter for a real deployment decision in 2026.

AttributePBKDF2Argon2 (Argon2id)
Introduced2000 (RFC 2898)2015 (Password Hashing Competition winner)
Formal standardNIST SP 800-132, RFC 8018RFC 9106 (IETF, 2021)
FIPS 140-3 approvedYesNo
Core designIterated HMAC (CPU-bound only)Memory-hard, tunable RAM + CPU + parallelism
Memory required per hashNegligible (a few KB)Tunable, OWASP minimum 19 MiB
OWASP 2025/2026 minimum config600,000 iterations (HMAC-SHA256)m=19 MiB, t=2, p=1
GPU cracking resistanceModerate, scales only with iteration countHigh, scales with memory + iterations + parallelism
VariantsHMAC-SHA1, HMAC-SHA256, HMAC-SHA512Argon2d, Argon2i, Argon2id
Side-channel resistanceData-independent by constructionArgon2id is hybrid-resistant; Argon2d alone is not
Typical server hash time~200 ms at 600,000 iterationsComparable, tuned via memory/time cost
Language/library supportUniversal, built into nearly every crypto libraryBroad and growing (libsodium, argon2-cffi, Bouncy Castle)
Best-fit use caseFIPS-regulated systems, legacy compatibilityNew applications with no compliance constraint

GPU Cracking Benchmarks: What the Numbers Actually Show

Three separate benchmark sources give a consistent picture, though they measure slightly different things, so it’s worth being precise about what each one actually tested.

Hashcat’s real-world PBKDF2 benchmark

Hashcat, the most widely used open-source password recovery tool, benchmarks hash mode 22000, which cracks WPA2/WPA3 Wi-Fi handshakes using PBKDF2-HMAC-SHA1 at exactly 4,096 iterations, the fixed iteration count baked into the 802.11i and WPA3-Personal specifications. On an RTX 4090, that mode runs at 2,516.4 kH/s (roughly 2.5 million guesses per second). That’s a genuine, directly measured PBKDF2 benchmark, but it’s important to note it reflects Wi-Fi’s fixed low iteration count, not the 600,000-iteration configuration OWASP recommends for password storage. It’s a useful reminder that “PBKDF2” isn’t one fixed speed, it’s a formula whose real-world cracking resistance depends entirely on the iteration count a given implementer chose.

Raw hash throughput vs Argon2id on the same GPU

A separate 2026 GPU cracking benchmark comparison measured raw hash throughput on the same class of hardware: an RTX 4090 computes roughly 21,900 million SHA-256 hashes per second, but only around 1,900 Argon2id hashes per second under a standard memory-hard configuration. That gap, roughly four orders of magnitude on the raw primitive, is the entire reason memory-hardness exists. Extrapolating from that raw SHA-256 rate, a full OWASP-strength PBKDF2 configuration at 600,000 iterations would run at roughly 36,500 guesses per second on the same GPU (21,900,000,000 divided by 600,000). Compared against Argon2id’s directly benchmarked 1,900 H/s, that puts Argon2id at roughly 22 times harder to brute-force per guess than a properly configured, full-strength PBKDF2, even before accounting for VRAM limits that cap how many parallel Argon2id guesses a single card can run at once.

GPU speedup over CPU

The same 2026 benchmark comparison also tested an AMD EPYC 9654 server CPU running Argon2id at around 210 hashes per second, versus 1,900 hashes per second on the RTX 4090. That’s roughly a 9x GPU speedup for Argon2id. For comparison, simple hashes like MD5 and SHA-1 see many-thousand-fold speedups moving from CPU to GPU. Memory-hardness doesn’t make GPU acceleration impossible, but it flattens the advantage from thousands of times faster down to single digits times faster, which is precisely the property OWASP and the Password Hashing Competition judges were optimizing for.

Why Memory-Hardness Beats Iteration Count

PBKDF2’s entire defense against brute force is the iteration count, and iteration count is a single-lever knob. Double the iterations, double the CPU cost for both the server and the attacker, and that’s the whole story. A GPU with 16,000 CUDA cores can run 16,000 independent PBKDF2 guesses at once because each guess needs almost no memory, just a small amount of register and cache space. That’s why raw SHA-256 throughput on an RTX 4090 lands in the tens of billions of hashes per second: the hardware was built to run enormous numbers of small, independent computations in parallel.

Argon2 attacks that assumption directly. Set the memory cost to 64 MiB and every single guess needs 64 MiB of dedicated RAM for the duration of the computation. An RTX 4090 has 24 GB of VRAM, which sounds like a lot until you divide it by 64 MiB per guess: that caps parallel guesses at roughly 375, not 16,000. Bandwidth becomes the bottleneck instead of compute, and GPUs, despite their raw compute power, don’t have proportionally more memory bandwidth than a well-specified CPU. That’s the mechanism behind the 22x gap measured above, and it’s why every current password-hashing guide, including OWASP’s, treats memory cost as the single most important Argon2 parameter to get right.

The same logic explains why ASICs, purpose-built chips designed to crack a single hash function far faster than any general-purpose processor, are far less of a threat against Argon2id than they were against algorithms like bcrypt or raw SHA-256. An ASIC gets its speed advantage by stripping out everything a CPU or GPU needs for general computation and wiring the remaining silicon directly into the target algorithm’s math. That works brilliantly when the algorithm barely touches memory. It works far less well when the algorithm’s entire cost model is built around forcing large, unpredictable memory reads, because adding more memory to a custom chip is expensive in exactly the way adding more arithmetic logic units is not. Attackers can still build memory-heavy ASICs, but the economics stop favoring them the way they did for PBKDF2 and bcrypt in the mid-2010s.

NIST SP 800-132, FIPS 140-3, and the Compliance Gap

This is the one area where PBKDF2 has no real competitor. PBKDF2 is defined in NIST SP 800-132 and is available inside FIPS 140-3 validated cryptographic modules, the certification that US federal agencies, defense contractors, healthcare systems under HIPAA, and much of the financial sector are required to use. Argon2 has no NIST SP 800-series publication and does not appear in FIPS-validated module boundaries as of 2025-2026. It’s not that Argon2 is considered weaker by regulators, memory-hardness is well understood and respected in academic cryptography, it simply hasn’t gone through NIST’s standardization and validation pipeline.

That gap shows up in real infrastructure. Linux’s LUKS2 disk encryption format, for example, defaults to Argon2 upstream, but distributions building FIPS-compliant cryptsetup packages override that default back to PBKDF2 specifically to stay inside validated module boundaries. Any organization that needs a FIPS 140-3 attestation today is choosing PBKDF2 not because it’s the better algorithm on paper, but because it’s the only one of the two that a compliance auditor can currently sign off on.

This is also why large software vendors that sell into both regulated and unregulated markets often end up shipping both algorithms side by side, the way Bitwarden and Django do, rather than picking one. A single codebase serving a federal government customer and a consumer signup flow needs PBKDF2 available for the former and benefits from Argon2id being available for the latter, and maintaining both isn’t nearly as costly as it sounds once the verify-then-upgrade pattern described later in this piece is in place.

OWASP’s Password Storage Cheat Sheet is the reference point nearly every engineering team defaults to, and its current guidance for both algorithms is specific enough to implement directly.

ConfigurationAlgorithmParameters
FIPS-140 requiredPBKDF2-HMAC-SHA256600,000 iterations minimum
PBKDF2 alternative hashPBKDF2-HMAC-SHA512220,000 iterations
PBKDF2 legacy-onlyPBKDF2-HMAC-SHA11,400,000 iterations
Default recommendationArgon2idm=19 MiB, t=2, p=1 (minimum)
Higher security, low iterationArgon2idm=46 MiB, t=1, p=1
Balanced profileArgon2idm=12 MiB, t=3, p=1
Lower memory profileArgon2idm=9 MiB, t=4, p=1
Lowest memory profileArgon2idm=7 MiB, t=5, p=1

Notice the tradeoff pattern in Argon2id’s profiles: as memory cost goes down, time cost goes up to compensate. That’s intentional. Applications that can’t spare 46 MiB per concurrent login, think high-traffic authentication servers handling thousands of logins per second, can drop to 7 MiB and make up the difference with more passes, at the cost of slightly higher CPU load per request.

Real-World Adoption: Where Each Algorithm Actually Runs

The cleanest way to understand the practical split between these two algorithms is to look at where each one is actually deployed today. Some of these are protocol-level defaults nobody can change without breaking interoperability, others are product decisions a vendor made deliberately, and one is a cautionary tale about what happens when an old default never gets revisited.

  • WPA2 and WPA3 Wi-Fi: Every WPA2-PSK and WPA3-Personal network derives its Pairwise Master Key with PBKDF2-HMAC-SHA1 at a fixed 4,096 iterations, producing a 256-bit key from the SSID and passphrase. That iteration count hasn’t changed since the original 802.11i specification, because it’s baked into interoperability requirements across every Wi-Fi device made.
  • LastPass: LastPass’s own December 2022 security notice described its default as “a stronger-than-typical implementation of 100,100 iterations” of PBKDF2. But independent analysis of the 2022 breach found many older accounts had never been migrated off far weaker historical defaults, some as low as 5,000 iterations, and in isolated cases as low as 500 or even 1, because LastPass never forced legacy vaults to re-key. That gap between the current default and what old accounts actually had is a large part of why the breach was as damaging as it was.
  • Bitwarden: Bitwarden added Argon2id as a selectable key derivation option starting with client version 2023.2.0 in February 2023. PBKDF2-SHA256 remains the default for new accounts, now set well above OWASP’s earlier minimums, but Argon2id is available as an opt-in upgrade in vault security settings for anyone who wants memory-hard protection.
  • Django: The Django web framework has shipped PBKDF2-SHA256 as its default password hasher for years, and has supported Argon2 as an optional hasher since Django 1.10. Enabling it requires installing the argon2-cffi package and listing Argon2PasswordHasher first in the PASSWORD_HASHERS setting, a five-minute change many teams still haven’t made.
  • LUKS2 disk encryption: Cryptsetup’s LUKS2 format, the standard for full-disk encryption on Linux, switched its default key derivation function from PBKDF2 (used in the older LUKS1 format) to Argon2 starting with cryptsetup 2.0 in 2018, moving from Argon2i to Argon2id in later releases for stronger combined resistance.
  • 1Password: 1Password uses PBKDF2 combined with HKDF in what it calls a two-secret key derivation scheme, folding both the account password and a separate high-entropy Secret Key into the final unlock key. Published iteration counts vary by client and era, ranging from roughly 100,000 up to 650,000, but the underlying algorithm has remained PBKDF2 rather than a memory-hard function, a deliberate design choice the company has acknowledged in public discussion of its architecture. The Secret Key itself, a long, high-entropy value generated on first setup and never derivable from the password alone, is doing a lot of the real security work here, which is part of why 1Password has been comfortable staying on PBKDF2 rather than following Bitwarden toward Argon2id.

Cost to Crack: What an Attacker Actually Pays

Cracking speed only matters in dollar terms once it’s converted into rental cost, since almost no attacker owns racks of GPUs outright anymore. Current 2026 on-demand cloud GPU pricing puts real numbers on that math.

GPU / providerOn-demand rateArgon2id guesses/hour (at 1,900 H/s)Extrapolated 600k-iter. PBKDF2 guesses/hour
RTX 4090, RunPod$0.34/hr~6.8 million~151 million
RTX 4090, Vast.ai (median)~$0.33-0.35/hr~6.8 million~151 million
RTX 5090, RunPod$0.69/hrHigher, not separately benchmarkedHigher, not separately benchmarked
RTX 5090, Vast.ai (median)~$0.40/hrHigher, not separately benchmarkedHigher, not separately benchmarked
AWS g5.2xlarge (A10G)$1.212/hrNot separately benchmarkedNot separately benchmarked
AWS p5.48xlarge (8x H100)$55.04/hr (~$6.88/hr per GPU)Not separately benchmarkedNot separately benchmarked

The middle two columns use the directly benchmarked and extrapolated RTX 4090 rates from the section above; the newer RTX 5090 and AWS figures are current sourced rental prices without a directly measured cracking benchmark on that specific hardware, so they’re left as rate comparisons rather than guessed throughput. Even at the conservative RTX 4090 numbers, a single dollar of rented GPU time buys an attacker roughly 20 million Argon2id guesses versus roughly 444 million PBKDF2 guesses at OWASP’s 600,000-iteration strength. Against a strong, random, 12-plus character password neither number matters much. Against a weak or reused password, that 22x gap is the difference between a leaked hash being cracked in hours versus weeks.

It’s worth noting that none of these hourly rates require an attacker to buy hardware at all. A decade ago, serious password cracking meant assembling a rig of consumer GPUs in a garage; today it means an hour on a marketplace like Vast.ai or RunPod with a credit card and no hardware ownership at all. That shift is a big part of why OWASP keeps raising its iteration and memory minimums every couple of years: the cost of renting compute keeps falling faster than most organizations update their hashing configuration.

Migrating From PBKDF2 to Argon2: A Step-by-Step Guide

Switching a live authentication system’s hashing algorithm without breaking every existing user’s login takes a specific sequence, since you can’t re-hash a password you never see in plaintext again.

  1. Confirm you don’t have a hard FIPS 140-3 requirement blocking the move; if you do, stop here and instead raise your PBKDF2 iteration count to OWASP’s 600,000-iteration minimum.
  2. Add an Argon2id library to your stack (libsodium, argon2-cffi for Python, or Bouncy Castle for Java/Kotlin are the most widely used).
  3. Set your target parameters. OWASP’s default profile is a reasonable starting point: m=19 MiB, t=2, p=1, and increase memory first if your login latency budget allows it.
  4. Add a hash-format identifier to your stored password records so your code can tell PBKDF2 hashes and Argon2id hashes apart at login time (most libraries already encode this in the hash string itself).
  5. On every successful login, check whether the stored hash uses the old algorithm. If it does, verify the password against PBKDF2 as before, then immediately re-hash the plaintext password with Argon2id and overwrite the stored value.
  6. Leave both verification paths active in your codebase for as long as your slowest-returning users need, typically 6 to 18 months, since some accounts may not log in again for a long time.
  7. Track migration progress with a simple metric: percentage of active accounts still on the old hash. Once it drops near zero, force a password reset for any remaining legacy accounts rather than keeping dual-algorithm support indefinitely.
  8. Load-test the new Argon2id parameters under realistic concurrent login volume before rolling out to 100% of traffic; memory-hard hashing multiplies RAM pressure on your authentication servers in a way PBKDF2 never did.

This pattern, verify-then-upgrade on login, is the same approach OWASP recommends generally for any hash algorithm migration, and it’s exactly what Bitwarden and similar services used when rolling out Argon2id as an opt-in option rather than forcing an instant cutover. The single most common mistake teams make during this process isn’t a technical one, it’s skipping step seven and leaving dual-algorithm support running indefinitely. Every extra month of supporting the old PBKDF2 verification path is another month a legacy account can sit at whatever iteration count it was created with, which is precisely the failure mode that turned an ordinary LastPass configuration gap into a headline breach.

PBKDF2 Pros and Cons

Weighing PBKDF2 fairly means separating the algorithm’s actual properties from the historical baggage of badly-configured deployments like early LastPass. Configured correctly, at current OWASP strength, it remains a legitimate choice, just one with a narrower set of ideal use cases than it had a decade ago.

  • Pro: The only one of the two algorithms available in FIPS 140-3 validated cryptographic modules.
  • Pro: Built into essentially every programming language’s standard or near-standard crypto library, no extra dependency required.
  • Pro: Minimal, predictable memory footprint, useful on constrained embedded devices.
  • Pro: Two decades of cryptanalysis with no fundamental structural weaknesses found.
  • Con: No memory-hardness, so raw iteration count is the only lever against GPU cracking, and that lever scales linearly while GPU compute keeps getting cheaper.
  • Con: Legacy deployments (LastPass being the clearest example) tend to accumulate old, under-configured hashes that never get re-keyed.
  • Con: At OWASP’s 600,000-iteration minimum, hash time is already around 200 ms on server hardware, leaving less headroom to simply add more iterations without hurting login latency.

Argon2 Pros and Cons

Argon2’s tradeoffs mostly show up on the operations side rather than the security side. The algorithm itself is well-regarded; the friction is almost entirely about compliance status and the extra server capacity planning that memory-hard hashing requires at scale.

  • Pro: Roughly 22x harder to brute-force per guess than full-strength PBKDF2 on the same GPU, based on benchmarked and extrapolated throughput.
  • Pro: Purpose-built winner of an open, multi-year cryptographic competition specifically judged on GPU and ASIC resistance.
  • Pro: Tunable across three independent dimensions (memory, time, parallelism), giving implementers more control to match their exact latency and security budget.
  • Pro: Argon2id variant resists both GPU-parallelism attacks and side-channel timing attacks simultaneously.
  • Con: Not available in FIPS 140-3 validated modules, a hard blocker for regulated industries.
  • Con: Higher memory pressure on authentication servers under heavy concurrent login load, since every simultaneous login needs its own memory allocation.
  • Con: Younger standard (RFC 9106 in 2021) with somewhat less universal library support than PBKDF2, though the gap is closing fast.

5 Use Cases and Which Algorithm Fits Best

  • New consumer web or mobile application, no compliance constraint: Use Argon2id at OWASP’s default profile. There’s no reason a greenfield product should ship with the weaker option in 2026.
  • Government, defense, or healthcare system requiring FIPS 140-3: Use PBKDF2-HMAC-SHA256 at 600,000 iterations or more. Argon2 is not currently an option inside validated module boundaries.
  • Existing product with millions of PBKDF2 hashes already stored: Don’t attempt a mass re-hash, since you can’t compute Argon2id from a hash you can’t reverse. Follow the verify-then-upgrade migration pattern above and let Argon2id adoption happen gradually on login, the same way Bitwarden and Django both structured their own rollouts.
  • Disk or full-volume encryption: Follow LUKS2’s lead and default to Argon2id unless a FIPS build specifically requires PBKDF2. Full-disk encryption typically unlocks once per boot rather than thousands of times per second, so Argon2id’s higher per-hash cost is rarely a practical concern here.
  • Embedded or resource-constrained device with strict RAM limits: PBKDF2 remains the more practical choice; Argon2’s memory requirement, even at OWASP’s lowest 7 MiB profile, can be a meaningful chunk of a small device’s total RAM, and some microcontroller-class hardware doesn’t have that much RAM to spare in the first place.
  • High-traffic authentication service handling thousands of concurrent logins: Test Argon2id’s lower-memory, higher-time-cost profiles (9 MiB or 7 MiB) before assuming the default 19-46 MiB profile fits your server capacity, and load-test under peak concurrent login volume, not average volume, before committing to a production rollout.

The Verdict: PBKDF2 vs Argon2 in 2026

For any team building something new with no regulatory constraint, Argon2id is the correct default in 2026. The benchmark data is consistent across every source checked here: Argon2id costs roughly 22 times more GPU-hours to brute-force than a properly configured, full-strength PBKDF2 implementation, and the gap only widens as GPU compute keeps getting cheaper relative to GPU memory bandwidth. RFC 9106 gives implementers a real standard to follow, and library support across Python, Java, Rust, and Go is mature enough that there’s no meaningful engineering excuse left to avoid it.

PBKDF2 isn’t going away, and it shouldn’t. It remains the only viable choice for FIPS 140-3 environments, it’s still what protects every Wi-Fi password on earth, and at 600,000-plus iterations it is not a weak algorithm, it’s simply a less efficient one than the memory-hard alternative that came fifteen years later. The real lesson from the LastPass example isn’t that PBKDF2 failed as an algorithm; it’s that an algorithm’s theoretical strength means nothing if legacy accounts never get migrated to current parameters. Whichever algorithm a team picks, the iteration or memory count set today needs a plan to increase again in a few years, because the GPU that makes this year’s numbers safe won’t be the GPU an attacker rents in 2029.

If there’s one number worth remembering from all of this, it’s not the 22x gap between the two algorithms, it’s the difference between LastPass’s 100,100-iteration current default and the 5,000-iteration default some of its own legacy accounts never left. Algorithm choice matters, but algorithm maintenance matters more. A team that picks PBKDF2 today and actually raises its iteration count on schedule every couple of years will end up safer than a team that adopts Argon2id once and never revisits its memory cost as GPUs get faster and VRAM gets cheaper.

Frequently Asked Questions

Is PBKDF2 still safe to use in 2026?

Yes, as long as it’s configured at OWASP’s current minimum of 600,000 iterations for HMAC-SHA256. The algorithm itself has no known structural break; the risk is almost always an outdated, low iteration count left over from years ago, which is exactly what happened to many legacy LastPass accounts.

Which is better, PBKDF2 or Argon2?

Argon2id is the stronger algorithm against GPU cracking, roughly 22 times harder to brute-force per guess at OWASP’s recommended settings, based on the benchmarks above. PBKDF2 remains the better choice specifically when FIPS 140-3 compliance is a hard requirement, since Argon2 isn’t currently available in FIPS-validated modules.

Why isn’t Argon2 NIST-approved?

Argon2 has not gone through NIST’s formal standardization and FIPS validation pipeline, and no NIST SP 800-series publication currently covers it. That’s a process and timeline issue rather than a security concern; the algorithm is well-studied and respected in academic cryptography, and it’s formally standardized by the IETF in RFC 9106.

OWASP’s minimum configuration is m=19 MiB, t=2, p=1. Higher-security alternatives include m=46 MiB at t=1, m=12 MiB at t=3, m=9 MiB at t=4, and m=7 MiB at t=5, all with parallelism set to 1, letting teams trade memory for time cost based on their server capacity.

How many PBKDF2 iterations should I use in 2026?

OWASP currently recommends a minimum of 600,000 iterations for PBKDF2-HMAC-SHA256, 220,000 for PBKDF2-HMAC-SHA512, and 1,400,000 for the legacy PBKDF2-HMAC-SHA1, which should only be used for backward compatibility with older systems.

Can I use Argon2 in a FIPS-compliant system?

Not currently. FIPS 140-3 validated cryptographic modules do not include Argon2 as of 2025-2026. Systems that must maintain FIPS compliance need to use PBKDF2, even in codebases like LUKS2 that default to Argon2 upstream and require a specifically configured, FIPS-oriented build to fall back to PBKDF2 instead.

Does Bitwarden use PBKDF2 or Argon2?

Both. Bitwarden accounts are created with PBKDF2-SHA256 by default, but Argon2id has been available as a selectable key derivation option since client version 2023.2.0, released in February 2023. Users can switch to it manually in their vault security settings.

What is the difference between Argon2i, Argon2d, and Argon2id?

Argon2d maximizes resistance to GPU cracking but is vulnerable to timing-based side-channel attacks, since its memory access pattern depends on the password being hashed. Argon2i randomizes that access pattern to resist those side-channel attacks but is somewhat weaker against GPU cracking as a result. Argon2id splits the difference: it runs as Argon2i for its first pass and Argon2d for the remaining passes, and that hybrid is the variant recommended by OWASP and specified as the default in RFC 9106 for password hashing specifically.