Argon2id vs PBKDF2: Why GPU-Resistant Key Derivation Matters

Introduction

A single RTX 4090 graphics card can test 1.4 billion PBKDF2-SHA256 guesses per second. If your password is 10 characters and uses common words, that’s minutes — not years.

This isn’t a hypothetical. Crackers rent GPU clusters on cloud services for dollars per hour. When a password database leaks (and they do), PBKDF2 is the algorithm that keeps defenders up at night.

Argon2id is the modern answer. It doesn’t just iterate — it forces attackers to use large amounts of RAM per guess, which is expensive and can’t be parallelized cheaply. This article explains how both algorithms work and why the difference matters for anything you encrypt with a password.

What Is a Key Derivation Function?

A key derivation function (KDF) takes a human password and turns it into a fixed-length cryptographic key suitable for encryption. You can’t use “MyPassword2024” directly as an AES-256 key — the math doesn’t work that way.

A KDF adds three protections:

1. Salting — A random value mixed in before hashing, so two users with the same password get different keys. This defeats precomputed rainbow table attacks.
2. Stretching — Deliberate slowness. The function runs thousands or millions of times, making brute-force guessing expensive.
3. Deriving a full-length key — Outputs exactly 256 bits (or whatever you need) regardless of the password length.

Both PBKDF2 and Argon2id are KDFs. They differ in what makes them slow.

How PBKDF2 Works

PBKDF2 (Password-Based Key Derivation Function 2) is defined in RFC 8018 and has been the standard since 2000. Its mechanism is simple:

1. Take your password + a random salt
2. Hash them with HMAC-SHA256 (or another digest)
3. Repeat that hash N iterations
4. The output is your derived key

The security parameter is iterations. More iterations = more work per guess.

Why PBKDF2 Falls Short Against GPUs

The critical weakness: PBKDF2 is compute-bound, not memory-bound. Every iteration is a tiny HMAC calculation — exactly the kind of operation modern GPUs are designed to run in parallel across thousands of cores.

At 600,000 iterations (OWASP’s 2024 minimum), a GPU still tests 2,300 guesses/second per card. An 8-character password using common words falls in minutes.

PBKDF2 remains adequate for server-side password storage at high iteration counts, but for key derivation from user passwords — especially in offline tools — it’s the wrong choice.

How Argon2id Works

Argon2id won the Password Hashing Competition in 2015 and became an IETF standard (RFC 9106) in 2021. Its core innovation is memory hardness.

Instead of just repeating a hash:

1. Password + salt → fill a large memory block (default: 64 MB)
2. Perform a series of memory-dependent computations across that block
3. The final hash depends on the entire memory state

Because each computation depends on a pseudo-random earlier memory location, the process can’t be meaningfully parallelized. An attacker who wants to test 1,000 guesses simultaneously needs 1,000 × 64 MB = 64 GB of RAM — not just more compute cores.

Argon2id Parameters

OWASP recommends three settings: a memory cost of 64 MB (meaning each hash occupies 64 MB of RAM for its duration), three passes over that memory, and four parallel threads. At these values, each hash attempt takes roughly 500ms–1 second on a modern server. The GPU advantage collapses because GPUs have thousands of fast cores but very limited RAM per core — the memory cost, not the compute cost, is what makes Argon2id expensive to attack in parallel.

VIDEO · READY 16:9

PLAY

How NOT to Store Passwords! — Computerphile

Argon2id vs PBKDF2 — Head to Head

The hash time is similar by design — you tune parameters so both take 1 second on your hardware. The difference is what an attacker needs to reach that time: for PBKDF2, more GPU cores; for Argon2id, more RAM.

Real-World Use Cases

Encrypted file backups When you encrypt a file with a password offline — using tools like our file encryptor, VeraCrypt, or Age — the KDF determines how long an attacker needs to crack a weak password. With PBKDF2, a short passphrase can fall in hours. With Argon2id at 64 MB, the same passphrase buys years.

Password manager master keys Password managers derive your vault key from your master password every time you unlock. A GPU-resistant KDF means a stolen encrypted vault stays secure even if the attacker has unlimited compute time. Bitwarden uses PBKDF2 (600,000 iterations) by default; 1Password uses Argon2id.

Developer authentication tokens When building an API that derives session keys from user passwords, always use Argon2id server-side. PBKDF2 was standard practice for years — many old codebases still use it. Upgrading the KDF on login (rehash and store) is one of the highest-leverage security improvements you can make.

Cryptocurrency wallets Every wallet that protects your seed phrase with a password uses a KDF to derive the encryption key. If an attacker steals your wallet file, the strength of the KDF determines how long your password holds out. A weak KDF like PBKDF2 with low iterations means a stolen wallet file is cracked in hours. Argon2id with OWASP parameters means months or years.

Common Mistakes to Avoid

• Using low iteration counts with PBKDF2: PBKDF2(password, salt, 10000) was once common. At 10,000 iterations, an RTX 4090 tests 140,000 guesses/second. Always use OWASP’s current minimum (600,000 iterations).

• Reusing salts: A fixed or sequential salt defeats the purpose of salting entirely. Every invocation must use a cryptographically random salt (16+ bytes from crypto.getRandomValues() or /dev/urandom).

• Using Argon2d instead of Argon2id: Argon2d is vulnerable to side-channel attacks. Unless you have a specific reason (GPU-only threat, no shared hardware), use Argon2id.

• Setting memory too low “for performance”: 4 MB memory cost turns Argon2id into a weaker version of bcrypt. The memory cost is the feature — don’t halve it to save 30ms.

Getting Started

If you’re evaluating tools or building something, look for Argon2id support in the library or service you’re using. Most modern languages have well-maintained Argon2 libraries. When you configure it, use OWASP’s recommended minimums: 64 MB memory, 3 iterations, and 4 parallel threads. If those settings cause a noticeable delay (over 2 seconds), reduce parallelism before reducing memory — the memory cost is the primary protection.

When comparing password managers or encryption tools, check their documentation for which KDF they use. Argon2id is the gold standard. If a tool still uses PBKDF2 with fewer than 600,000 iterations, that’s a meaningful security gap worth flagging.

If you inherited a system using PBKDF2 and want to upgrade, the standard approach is to re-hash passwords on the next successful login — verify the old PBKDF2 hash, then store a new Argon2id hash. Users are transparently upgraded without a forced password reset, and over time the legacy hashes phase out naturally.

For a deeper look at how these keys protect your actual file content, see our article on AES-256-GCM authenticated encryption. To understand why hashing and encryption are different problems with different solutions, read our guide on hashing vs encryption.