PBKDF2 (Password-Based Key Derivation Function 2) is a key stretching algorithm defined in RFC 2898 / PKCS #5. It applies a pseudorandom function—typically HMAC (Hash-based Message Authentication Code)—to the password and salt repeatedly for many iterations. This makes brute-force attacks significantly more expensive. Each iteration feeds its output as input to the next, creating a chain that's computationally intensive to reverse.

A salt is a random value added to the password before hashing. It serves two critical purposes: (1) It ensures that identical passwords produce different derived keys, preventing attackers from using precomputed rainbow tables. (2) It makes dictionary attacks harder because each salt requires a separate brute-force effort. Use at least 16 bytes (128 bits) of cryptographically random salt, unique per user or per derivation.

OWASP 2023 guidelines recommend:

• SHA-256: at least 600,000 iterations
• SHA-512: at least 210,000 iterations

The ideal count depends on your hardware and acceptable delay. Generally, aim for a derivation time of 100–500 ms on your production server. Higher counts improve security but impact user experience during login. Test on your target hardware.

Argon2 (winner of the Password Hashing Competition) is the modern gold standard—it's memory-hard, making GPU/ASIC attacks difficult. scrypt is also memory-hard but older. bcrypt is GPU-resistant but limited to 72-byte passwords. PBKDF2 is the most widely supported, NIST-approved, and FIPS-140 compliant, making it the go-to for regulated industries. If compliance isn't a concern, Argon2id is recommended. PBKDF2 remains a solid, well-understood choice.

Match the key length to your use case:

• 32 bytes (256 bits) — AES-256 encryption keys, most common
• 16 bytes (128 bits) — AES-128, session tokens
• 64 bytes (512 bits) — HMAC-SHA512 keys, split keys

Don't request more than the hash's native output length multiplied by a reasonable factor—excessive lengths don't add security and increase computation time.

While SHA-1 is considered broken for collision resistance, PBKDF2-HMAC-SHA1 is still considered secure because PBKDF2 relies on HMAC's preimage resistance, not collision resistance. However, for new systems, always prefer SHA-256 or SHA-512. SHA-1 is only included here for compatibility with legacy systems.

Yes. PBKDF2 is commonly used to hash passwords for storage. Store the salt, iteration count, and derived key together (e.g., in a single database row). During login, re-derive the key from the candidate password with the stored salt and iterations, then compare. Always use a constant-time comparison to prevent timing attacks.

PBKDF2's main limitation is that it's not memory-hard. Attackers can parallelize brute-force attacks using GPUs, FPGAs, or ASICs relatively efficiently compared to memory-hard algorithms like Argon2. It also has a theoretical maximum output length based on the underlying hash function. For most web applications, however, PBKDF2 with a high iteration count provides adequate security.

This tool uses the browser's built-in Web Crypto API (crypto.subtle.deriveBits), which leverages the operating system's cryptographic primitives. In most modern browsers, PBKDF2 computations are offloaded to a separate thread, keeping the UI responsive. The API requires a secure context (HTTPS or localhost) and supports SHA-1, SHA-256, SHA-384, and SHA-512 as the underlying HMAC hash.