Why Plain Hashing Isn’t Enough for Passwords
SHA-256 hashes a string in nanoseconds. That’s great for file checksums. It’s terrible for passwords. A modern GPU can compute roughly 8.5 billion SHA-256 hashes per second. An attacker with a leaked database of SHA-256 password hashes can try the entire rockyou.txt wordlist (14 million common passwords) in under a millisecond.
PBKDF2 fixes this by being deliberately slow. It takes your password, mixes in a random salt, then runs SHA-256 not once but hundreds of thousands of times. At 600,000 iterations (OWASP’s current recommendation for PBKDF2-SHA256), each hash takes a noticeable fraction of a second. That’s fine for logging in once. It’s devastating for an attacker who needs to test billions of guesses.
This tool hashes passwords with PBKDF2-SHA256 and generates a random 128-bit salt for each operation. It also verifies passwords against existing hashes. Everything runs in your browser via the Web Crypto API.
The Salt Makes All the Difference
Without salt, identical passwords produce identical hashes. An attacker can precompute a rainbow table — millions of password-to-hash mappings — and look up hashes instantly. Game over.
Salt is a random value mixed into the hash. Even if two users both pick “password123,” their hashes are completely different because their salts are different. Rainbow tables become useless because the attacker would need a separate table for every possible salt value. With a 128-bit salt, that’s 3.4 x 10^38 possible tables.
The output format is iterations:salt:hash, all in hex. Everything needed to verify the password later is right there in one string.
Choosing Your Iteration Count
100,000 iterations is a reasonable baseline. Hash computation takes about 50-100ms on most devices, which is imperceptible during login but makes brute-forcing painful.
600,000 iterations is what OWASP recommended in their 2023 password storage guidelines for PBKDF2-SHA256. It’s slower — maybe 200-400ms per hash — but substantially more secure against offline attacks.
Try both in this tool. Hash the same password at 10,000 iterations, then at 600,000. You’ll feel the speed difference. Now imagine an attacker who has to do that for every single guess in a dictionary attack. That’s the whole point.
Development and Testing
You’re building a Node.js auth system with PBKDF2. Your Python microservice also needs to verify the same hashes. How do you know both implementations produce the same output?
Hash a known password here with known parameters. Take the output — 600000:a1b2c3...:d4e5f6... — and verify it against your Node implementation. Then verify against your Python implementation. If both match, your code is correct. If one doesn’t, you’ve got a bug to track down (usually a character encoding issue or a hex-vs-raw-bytes mismatch).
PBKDF2 vs. bcrypt vs. Argon2
bcrypt is excellent, but it can’t run in the browser — the Web Crypto API doesn’t support it. Argon2 is the newest and generally considered the strongest (it’s memory-hard, which resists GPU attacks), but it also lacks browser support. PBKDF2 is the only password hashing algorithm fully supported by the Web Crypto API, and it’s still NIST-approved and widely used.
For production systems, implement whichever algorithm your server-side language supports best, with timing-safe comparison and secure storage. The hashes from this tool are algorithmically correct reference values for testing.
The Hash Generator shows how a plain SHA-256 hash of a password looks — compare it to PBKDF2 output to see why key stretching matters. The Password Generator creates strong random passwords to hash.