PBKDF2 Hash Generator
Free online PBKDF2 Hash Generator tool. 100% local processing — your data never leaves your device.
Result will be displayed here...
Input → Calculate Hash
Usage Guide
About PBKDF2
PBKDF2 (Password-Based Key Derivation Function 2) is a key derivation function standardized in RFC 8018 (PKCS#5) and NIST SP 800-132. Unlike a simple hash function, PBKDF2 is specifically designed to derive a cryptographic key from a password by applying a pseudorandom function (HMAC-SHA256 or HMAC-SHA512) thousands or hundreds of thousands of times. This makes brute-force attacks computationally expensive. PBKDF2 is FIPS 140-2 compliant and widely used in LUKS disk encryption, WPA2/WPA3 Wi-Fi, iOS/Android secure storage, and password managers.
Usage Steps
This tool supports two operations: deriving a key (Encrypt mode) and verifying a password (Decrypt mode):
Parameters Guide
PBKDF2 has four key parameters that control the security and output of the derived key:
PBKDF2 vs Argon2 / bcrypt
Understanding when to choose PBKDF2 over other password hashing algorithms:
FAQ
Q: What is the PBKDF2 output format?
A: This tool outputs a self-contained hash string: {iterations}:{algorithm}:{salt_base64}:{derived_key_hex}.
For example: 600000:sha256:abc123...==:d4e5f6....
Components:iterations: Number of HMAC rounds used (e.g., 600000).algorithm: Hash function (sha256 or sha512).salt_base64: Base64-encoded random salt.derived_key_hex: Hex-encoded derived key output.
To verify, enter: password|{the full hash string} in Decrypt mode.
Q: Why does PBKDF2 need 600,000 iterations?
A: PBKDF2 is not memory-hard — it can be parallelized on GPUs cheaply. A modern GPU can compute roughly 1–2 billion PBKDF2-SHA256 iterations per second. At 600,000 iterations per hash, that still allows ~1,600 hash attempts per second per GPU. The high iteration count is the primary defense mechanism — it directly multiplies attacker cost. OWASP 2023 sets 600,000 as the minimum for SHA-256; use 210,000 for SHA-512 (which is naturally slower). Increase these values as hardware improves over time.
Q: How is PBKDF2 different from bcrypt or Argon2?
A: PBKDF2: Computation-hard only, not memory-hard. GPU-parallelizable. FIPS 140-2 approved. Requires very high iterations. Best for FIPS-regulated environments. bcrypt: Computation-hard, ~4KB memory, moderate GPU resistance. 72-byte password limit. Cannot derive arbitrary-length keys. Argon2id: Memory-hard, GPU/ASIC resistant, modern OWASP preference. Not FIPS-approved. Performance at equivalent security: Argon2 is significantly faster than PBKDF2 at the same effective security level due to memory hardness.
Q: Is PBKDF2 FIPS 140-2 compliant?
A: Yes. PBKDF2 is explicitly defined in NIST SP 800-132 and approved under FIPS 140-2. This makes it the mandated choice for US federal agencies, contractors, healthcare systems subject to HIPAA, and financial applications requiring PCI-DSS compliance. Argon2 and scrypt are not FIPS-approved. If FIPS compliance is required, PBKDF2 is currently the only widely available option. Always verify that your PBKDF2 implementation uses a FIPS-validated cryptographic module.
Q: Why is the salt important and must it be stored?
A: The salt is a random value added to the password before hashing to ensure two identical passwords produce different derived keys. Without a salt, attackers can use precomputed rainbow tables to crack multiple hashes simultaneously. The salt does not need to be secret — it just needs to be unique per password. The salt is included in the output string and must be stored alongside the derived key to reproduce the same hash during verification. Never reuse salts across passwords.
Q: How do I use PBKDF2 for AES key derivation?
A: Set the key length to 32 bytes (256 bits) to derive an AES-256 key directly. Use 600,000 iterations with SHA-256. Store the salt with your encrypted data. During decryption, re-derive the key using the same password, salt, iterations, and algorithm, then use it to decrypt with AES-256-GCM. This is exactly how LUKS disk encryption, iOS data protection, and many password managers work. The derived key is deterministic — same inputs always produce the same key — which is why protecting the password and using unique salts is critical.
Use Cases
Recommended: FIPS-Compliant Password Storage
Organizations subject to FIPS 140-2, NIST SP 800-131A, HIPAA, or PCI-DSS must use approved cryptographic algorithms. PBKDF2 with HMAC-SHA256 or HMAC-SHA512 is the only widely available password KDF that meets these requirements. Use at least 600,000 iterations for SHA-256 and store the full output string. This is the primary reason to choose PBKDF2 over Argon2id in regulated environments.
- ✅ PBKDF2-HMAC-SHA256 (≥600,000 iterations) — FIPS compliant
- ✅ PBKDF2-HMAC-SHA512 (≥210,000 iterations) — FIPS compliant
- ❌ Argon2 / scrypt — not FIPS 140-2 approved
- ❌ bcrypt — not FIPS 140-2 approved
Recommended: Disk Encryption Key Derivation (LUKS)
LUKS (Linux Unified Key Setup) uses PBKDF2 by default (LUKS1) and PBKDF2/Argon2 (LUKS2) to derive the volume encryption key from a passphrase. PBKDF2 derives a fixed-length key (32 bytes for AES-256) from the user's passphrase, which is then used to encrypt the master key stored in the LUKS header. This ensures that even knowing the LUKS header does not reveal the passphrase. WPA2/WPA3 Wi-Fi security also uses PBKDF2 to derive the Pairwise Master Key (PMK) from the Wi-Fi password.
- ✅ PBKDF2-HMAC-SHA512 (LUKS1 standard)
- ✅ Argon2id (LUKS2 preferred — better memory hardness)
- 💡 Set iterations high enough that derivation takes 0.5–2 seconds on target hardware
- 💡 Store salt in the disk/header metadata, never separately
Acceptable: Password Verification in Legacy Systems
Many existing systems (older Django versions, .NET Membership, Java PBKDF2WithHmacSHA1) already store PBKDF2 hashes. Continue using PBKDF2 for these systems and gradually raise the iteration count as hardware improves. Use the stored iteration count for verification (it's embedded in the hash string), and update to current OWASP recommendations for new registrations and password changes. This avoids forced password resets while improving security over time.
- ✅ PBKDF2 (keep for existing hashes — no migration required)
- ✅ Increase iterations for new hashes to current OWASP minimum
- 💡 Transparently upgrade iteration count on next login
- 💡 Consider migrating to Argon2id for new projects if FIPS is not required
Acceptable: Deriving Multiple Keys from One Password
PBKDF2 can derive keys of arbitrary length, making it useful when multiple keys are needed from one master password (e.g., one key for encryption, another for MAC authentication). Use different salts or index suffixes to derive independent keys. Set the key length parameter to 64 bytes and split the output into two 32-byte keys, or run PBKDF2 twice with different salts. This pattern is used in some password manager architectures and multi-layer encryption schemes.
- ✅ Use different salts per derived key purpose
- ✅ Use HKDF (HMAC-based Key Derivation Function) for key expansion after initial PBKDF2 derivation
- ❌ Never reuse the same salt for different key purposes
- 💡 Combine with AES-256-GCM for authenticated encryption
Not Recommended: Replacing Argon2 in New Projects
If you are starting a new project without FIPS requirements, PBKDF2 is the weaker choice compared to Argon2id. PBKDF2 is not memory-hard, meaning GPUs can parallelize attacks cheaply. Even at 600,000 iterations, a single high-end GPU can attempt thousands of PBKDF2 guesses per second. Argon2id with default parameters (47MB memory, 1 iteration) achieves comparable wall-clock time while requiring memory that prevents GPU parallelization entirely.
- ❌ Avoid PBKDF2 for new projects when Argon2id is available
- ✅ Argon2id (memory-hard, OWASP preferred)
- ✅ scrypt (memory-hard, widely available)
- 💡 PBKDF2 is only preferred when FIPS compliance is mandatory
Not Recommended: General Data Hashing
PBKDF2 is a key derivation function, not a general-purpose hash function. It is intentionally slow and should never be used for hashing file contents, checksums, message authentication, or deduplication. For data integrity, use SHA-256 or SHA-512. For message authentication, use HMAC-SHA256. PBKDF2's output is a derived key — using it as a general hash would waste significant CPU cycles without any security benefit.
- ❌ Don't use PBKDF2 for file checksums or data integrity
- ❌ Don't use PBKDF2 for message authentication (use HMAC-SHA256)
- ✅ SHA-256 / SHA-512 for general data hashing
- ✅ HMAC-SHA256 for authenticated message integrity
Best Practice Summary
- Use PBKDF2-HMAC-SHA256 with ≥600,000 iterations (or HMAC-SHA512 with ≥210,000) for FIPS-compliant environments. Store the full hash string including iterations, algorithm, and salt.
- For new projects without FIPS requirements, prefer Argon2id — it is memory-hard and significantly more resistant to GPU attacks at comparable performance.
- Always use a unique random salt per password (auto-generated by this tool). Never reuse salts or hardcode them in application code.
- Increase iteration counts over time as hardware improves. The iteration count is stored in the hash string, so old and new counts can coexist.
- Use PBKDF2 only at login or key setup — never on every request. Issue tokens (JWT, session) after authentication for high-frequency operations.