All articles

PBKDF2: the oldest key-stretching standard

PBKDF2 has a very specific numeric backstory in U.S. standards: NIST Special Publication 800-132 formalized it for password-based key derivation, and modern guidance (echoed by OWASP) recommends at least 600,000 iterations for PBKDF2-HMAC-SHA256 as of 2023 — a number that has climbed steadily as hardware got faster, from tens of thousands a decade ago.

The key-stretching principle

Instead of hashing a password once, PBKDF2 applies a base hash function (usually HMAC-SHA256) many thousands of times in a row, feeding each iteration's output as input to the next. This deliberately slows down computing a single hash, making mass brute-forcing significantly more expensive for an attacker.

Why this site's PBKDF2 tool needs HTTPS

This tool computes PBKDF2 using the browser's built-in Web Crypto API (crypto.subtle.deriveBits) rather than a hand-rolled JavaScript implementation — faster, audited, and constant-time where it matters. But the Web Crypto API is only exposed in a "secure context": browsers refuse to expose crypto.subtle over plain HTTP (localhost is exempted for development), which is why every tool on this site that touches cryptography requires HTTPS to function at all.

Why PBKDF2 is less resistant than Argon2 or scrypt

Because PBKDF2 only requires computation and no significant memory, it's easier and cheaper to attack on specialized hardware (GPUs, ASICs) that efficiently parallelizes exactly that kind of computation. That's why memory-hard algorithms are more often recommended for new systems, though PBKDF2 remains a widely supported standard.

Why you'd need this

  • Deriving cryptographic keys from passwords for encryption (e.g. in WPA2/WPA3 for Wi-Fi).
  • Maintaining compatibility with legacy systems that use PBKDF2 for password storage.
  • Understanding why the recommended iteration count keeps rising in newer versions of standards.

The choice of underlying hash function matters

Older PBKDF2 implementations often defaulted to HMAC-SHA1 — SHA-1 itself is considered cryptographically weakened for direct hashing, but that weakness isn't a critical vulnerability within the HMAC construction. Still, modern guidance consistently recommends HMAC-SHA256 or HMAC-SHA512 — not because of a direct threat from SHA-1, but because a longer output and a more modern function give a larger safety margin at negligible speed cost.

Try the tool