PBKDF2 Hash Generator

Use this PBKDF2 hash generator to combine a plain-text password with a random salt and get a PBKDF2 hash you can store, compare or test against another library. Choose a hash algorithm, an iteration count and a key length, click the button, and the derived key appears in your preferred output format. It is a fast, cryptographic sandbox for seeing how password hashing behaves before you build it into a real login system.

How the PBKDF2 Hash Generator Turns a Password into a Derived Key

PBKDF2 stands for Password-Based Key Derivation Function 2. It is a standardized key derivation function defined in PKCS #5, first published as RFC 2898 and later refreshed as RFC 8018. The algorithm feeds your password and salt into an HMAC hash function, then repeats that step thousands of times so every guess an attacker makes costs real processing time. That deliberate slowness is what makes the scheme computationally intensive for anyone trying to crack a stolen database. Run the free mysql password hash generator whenever you need another one — it only takes a few seconds.

The calculation behind each block of the derived key looks like this:

$$U_1 = \mathrm{HMAC}(P,\ S \parallel i), \qquad U_j = \mathrm{HMAC}(P,\ U_{j-1}), \qquad T_i = U_1 \oplus U_2 \oplus \cdots \oplus U_c$$

$$DK = T_1 \parallel T_2 \parallel \cdots \parallel T_{\lceil dkLen / hLen \rceil}$$

Here \(P\) is the password, \(S\) is the salt, \(c\) is the number of iterations, \(dkLen\) is the requested key length and \(hLen\) is the digest size of the chosen hash function. Every extra iteration adds one more HMAC call, so the work grows in a straight line with \(c\).

Salt: Why Every Hash Needs a Random Salt

A salt is random data mixed into the password before hashing. Because each account gets its own value, two users with the same password end up with completely different hash digests, and attackers cannot reuse precomputed tables. It is the reason rainbow tables stopped being a practical shortcut. A random salt of at least 16 bytes is the usual minimum, and the generator can create one for you using a secure source of randomness.

Iteration Count and Brute-Force Cost

The iteration count is the dial that sets how expensive each guess is. Doubling the iterations doubles the time an attacker needs per guess against a brute-force attack, and it doubles the time your own server spends on every login. You are always balancing those two costs, which is why current guidance gives a floor rather than a ceiling.

Worked Example: Generate PBKDF2 Hash Output with SHA-256

To see exactly what the tool returns, here is one run with values chosen for this guide. The password is maple-orbit-quartz-58, the salt is a 16-byte value written in hex, and the hash function is HMAC-SHA-256 with 600,000 iterations and a 32-byte key. Use the free argon2 hash generator to get a result in seconds — right in your browser.

Run the same inputs again and you get the identical string, because PBKDF2 hashes are deterministic. Change a single character of the password, one byte of the salt or one iteration and the whole output changes. On a typical laptop this run took about 130 milliseconds.

Reading the Output Format: Hex vs Base64

The output format only changes how the same bytes are written. Hex uses two characters per byte, so a 32-byte key is 64 characters long, while Base64 packs the same key into 44 characters. Neither is more secure, so pick whichever your storage format or library expects.

Choosing a Hash Algorithm for PBKDF2 Password Hashing

The hash algorithm is the pseudo-random function that sits inside every iteration. For PBKDF2 password hashing, the OWASP Password Storage Cheat Sheet publishes a minimum iteration count for each option, because a faster digest needs more rounds to cost the same.

Measured on the same laptop with the worked-example inputs, those three settings took roughly 330 ms for SHA-1, 130 ms for SHA-256 and 90 ms for SHA-512. The numbers are close enough that the safer choice is simply the one your platform supports natively. Pick SHA-256 for the widest interoperability.

Auditing a Legacy Login with a PBKDF2 Password Hash

Dana, a backend developer, inherits a small member portal whose user table stores SHA-256 hashes with 150,000 iterations. Before touching production, Dana wants to know how far that sits from the OWASP floor of 600,000 for HMAC-SHA-256, and what a bump costs per login.

She opens the tool and enters the test password kestrel-ledger-7714, the 16-byte salt c41e07b9d25a63f81b90e4a7d3c5682f, SHA-256 and a 32-byte key. At 150,000 iterations the derived key begins be091cd4 and the run takes 33 ms. That matches the record she computed with the portal's own code, so the stored format is confirmed: parameters read correctly, nothing misparsed.

Next she changes only the iteration count to 600,000. The key becomes 0798212a, a completely different value, and the time rises to 131 ms, almost exactly four times the old cost. That ratio is what the key derivation function promises, because work grows in a straight line with the iterations.

• Current setting: 150,000 iterations, 33 ms, one quarter of the OWASP minimum.
• Target setting: 600,000 iterations, 131 ms per hash.
• Login load: 40 sign-ins per minute adds under 6 seconds of CPU time per minute, so the server absorbs it easily.

The decision is concrete: upgrade each hash the next time its owner signs in, since the plain-text password is only available at that moment. The login code verifies against the old 150,000-iteration record, then re-hashes with 600,000 iterations and a fresh salt, and stores the new parameters beside the hash. Dana keeps the 150,000-iteration path for accounts that have not signed in, and schedules a review of that cohort in 90 days.

Key Length and Salt Size Settings for a Key Derivation Function

Two size settings shape every PBKDF2 hash. The key length (also called key size or dkLen) is how many bytes of output you want. Asking for more bytes than the digest provides forces extra blocks, which doubles the work for the defender without making an attacker's job any harder, so keep it equal to the digest size. The salt size is separate and should not shrink below 16 bytes.

• Match the key length to the hash function: 32 bytes for SHA-256, 64 bytes for SHA-512.
• Store the salt, iteration count and algorithm next to the stored hash so every record can be checked later.
• Never reuse one salt across accounts, and never derive it from the username alone.
• Use the same hash function and parameters when you verify as when you generate.

PBKDF2 vs Argon2, bcrypt and scrypt

PBKDF2 is not the newest design. Argon2, bcrypt and scrypt all add memory cost, which blunts GPU attacks in a way PBKDF2 cannot.

When PBKDF2 Is Still the Right Call

Choose PBKDF2 when a regulator, a hardware module or a framework requires a standards-based option. The NIST guidelines accept it, and it ships in Java, OpenSSL, .NET, Python and the Web Crypto API for JavaScript. For a brand-new service with free choice, Argon2id is the stronger recommendation.

Verifying a PBKDF2 Password Hash Safely

Verification reverses nothing, because the hash cannot be reversed. Instead the checker reads the algorithm, salt and iterations from the stored value, recomputes the hash from the candidate password and compares the two. A constant-time comparison matters here, since a normal string comparison stops at the first wrong byte and can leak information through timing attacks. This is the same flow real authentication code follows, and it is why the generator output includes every parameter.

Reading the Security Summary

A good security summary flags weak settings and gives recommendations: too few iterations, a short salt or an outdated digest each deserve warnings. Treat it as a quick check of your security posture, not a guarantee.

PBKDF2 Tool Uses for Developers and Students

Developers use a PBKDF2 tool to produce test fixtures, to confirm that a hash written in one language matches another, and to migrate old passwords to stronger parameters. Beyond password storage in databases, the same password-based key derivation function creates encryption keys and authentication tokens for disk and file encryption, where the derived keys protect other data. Students of cryptography get a hands-on view of how unique salts and iterations change a result.

Keep the limits in mind: a browser page is for educational purposes and testing. For production systems, compute hashes on the server-side with a vetted library, because client-side code exposes the password to scripts and extensions. Cloud platforms and managed services follow the same standards, and this PBKDF2 hash generator is simply the quickest way to check your settings first. Done well, it makes your security choices visible instead of guessed.

Frequently Asked Questions

What is PBKDF2 and why does it need a salt and iteration count?

PBKDF2 (Password-Based Key Derivation Function 2, RFC 8018) deliberately slows down key derivation by repeating the underlying HMAC computation many times (the iteration count) -- this makes brute-force attacks against a stolen hash dramatically more expensive. The salt (a random value stored alongside the hash) ensures two users with the same password get completely different derived keys, defeating precomputed rainbow-table attacks.

How many iterations should I use?

OWASP's current recommendation for PBKDF2-HMAC-SHA256 is at least 600,000 iterations (this tool's default) as of their 2023+ guidance -- higher is more secure but slower for legitimate use too, so the right number balances your threat model against acceptable login latency.

Should I keep the salt secret?

No -- the salt is meant to be stored alongside the derived key/hash, not kept secret. Its job is to make every derivation unique, not to add secrecy; PBKDF2's actual security comes from the password's own entropy and the iteration count.

What's the difference between the hex and Base64 output?

They're the exact same derived key bytes, just encoded differently -- hex is more human-readable for debugging, while Base64 is more compact and is what many systems (including Django's password hasher) actually store in their password field format.

Is my password sent anywhere?

No. The entire derivation runs locally using the Web Crypto API -- your password, salt, and derived key are never transmitted to a server or stored.