Advertisement

PBKDF2 key derivation

Derive cryptographic keys from passwords with PBKDF2 using your browser's Web Crypto API. Choose the PRF, iteration count, salt and output length.

Derive a key

PBKDF2 via the Web Crypto API. Needs a secure context (HTTPS or localhost).

OWASP suggests 600,000 for HMAC-SHA-256 in production.
Needs a secure context (HTTPS or localhost) for the Web Crypto API. Nothing is uploaded.
PBKDF2

The derived key appears below in your chosen encoding.

-
Advertisement

How PBKDF2 works

PBKDF2 (RFC 8018) applies a pseudorandom function, usually HMAC-SHA-256, to the password and salt, then iterates that thousands of times, XORing the results. The iteration count is the work factor: each guess by an attacker must repeat the full chain. A unique random salt per password stops rainbow tables.

Iteration guidance

OWASP currently recommends 600,000 iterations for PBKDF2-HMAC-SHA-256 (210,000 for SHA-512) for password storage. Higher is better, but balance against login latency; this page lets you experiment. For new designs, consider Argon2id or scrypt, which add memory hardness that PBKDF2 lacks.

PBKDF2 Hash FAQs

How many iterations should I use?
OWASP 2023 guidance: 600,000 for HMAC-SHA-256, 210,000 for HMAC-SHA-512. This demo defaults to 100,000 so your browser stays responsive; raise it in production.
Which PRF is best?
HMAC-SHA-256 is the standard default. HMAC-SHA-512 lets you use fewer iterations for the same work. HMAC-SHA-1 is legacy.
What salt should I use?
A unique, random 128-bit salt per password, stored alongside the hash. Never reuse salts or use a fixed application-wide salt.
PBKDF2 vs bcrypt vs Argon2?
PBKDF2 is NIST-approved and FIPS-friendly but only CPU-hard. bcrypt adds some GPU resistance; Argon2id adds memory hardness and is the modern recommendation.
Why HTTPS?
PBKDF2 here uses the Web Crypto API, which requires a secure context (HTTPS or localhost).
Advertisement