Password Storage Lab
Almost every password breach is a storage failure: plaintext, or a bare fast hash with no salt. This lab runs real PBKDF2 and SHA-256 in your browser with the Web Crypto API — derive a key and feel the cost of a single guess climb as you raise the iterations, crack an unsalted MD5 dump by looking it up in a rainbow table, then add a unique per-user salt and watch that table go dead. Then make the calls — adequate work factor, unique salt, memory-hard over fast, salt vs pepper, and never roll your own — and get graded.
The real job. More noise, a tighter clock.
Work the password bench
6 graded challenges that use real PBKDF2 and SHA-256 in your browser via the Web Crypto API — derive a key and feel the cost of raising iterations, crack an unsalted MD5 dump with a rainbow-table lookup, watch a per-user salt erase it, and rank plaintext through Argon2id. Score on correct parameter, crack, and ranking decisions. Clear 75% to pass — finish under par for a speed bonus and a better grade.
What this lab is
- A free, 100% in-browser cryptography lab that runs REAL PBKDF2 and SHA-256 via the Web Crypto API — no server, no account, nothing leaves your machine.
- Derive a key with crypto.subtle PBKDF2-SHA256 and a random salt, then raise the iteration count and watch the wall-clock cost of a single guess climb — the whole point of a work factor.
- Crack an unsalted MD5 dump of common passwords by rainbow-table lookup — exactly what an attacker does — then add a unique per-user salt and watch the salted digests vanish from the table.
- Rank the schemes by how expensive one guess is: plaintext < unsalted MD5 < salted SHA-256 (fast) < PBKDF2 < bcrypt < Argon2id / scrypt (memory-hard).
- Graded decisions drill the real lessons: ≥600k PBKDF2 iterations (current OWASP floor) + a unique salt, salt vs pepper, memory-hard over compute-only, and why you never roll your own.
Frequently asked questions
What is the Password Storage Lab?
A free, browser-based cryptography trainer that uses the real Web Crypto API (crypto.subtle) to teach safe password storage. You derive keys with live PBKDF2-HMAC-SHA256, feel how raising the iteration count raises the cost of each guess, crack an unsalted MD5 hash dump with a rainbow-table lookup, watch a unique per-user salt defeat that precomputed table, and work through graded challenges on parameters, salt vs pepper, scheme ranking, and why homegrown hashing fails. Everything runs client-side — nothing is sent to a server.
Why are unsalted MD5 or SHA-1 password hashes unsafe?
Those hashes are extremely fast to compute and, with no salt, identical passwords produce identical digests. An attacker precomputes (or downloads) a table mapping the hash of every common password back to its plaintext and reverses an entire leaked dump by lookup in seconds — no real cracking needed. A unique, random per-user salt makes every hash different so precomputed and rainbow tables no longer apply, and a slow, ideally memory-hard function (Argon2id, scrypt, bcrypt, or PBKDF2 at a high iteration count) makes mass guessing expensive.
How many PBKDF2 iterations should I use?
OWASP’s current Password Storage Cheat Sheet puts the floor for PBKDF2-HMAC-SHA256 at 600,000 iterations, always with a unique random per-user salt. Older figures like 100,000 are now too low. Because PBKDF2 is compute-only (not memory-hard) it parallelises cheaply on GPUs and ASICs, so where you can, prefer a memory-hard function such as Argon2id or scrypt, tuned so a single verification takes a target amount of time and memory.
What is the difference between a salt and a pepper?
A salt is unique per user, is not secret, and is stored right alongside the hash — its job is to make every hash unique so precomputation fails. A pepper is a single application-wide secret kept OUT of the database (in an environment variable, secret manager, or HSM) and mixed into every hash, so that a database-only leak still cannot be brute-forced. They are complementary: you keep both, and neither replaces a high work factor.
Is any of this sent to a server?
No. The lab is entirely client-side and uses your browser’s built-in Web Crypto implementation for PBKDF2 and SHA-256. Passwords, salts and derived keys stay in the page; your best grade is saved only in your own browser’s local storage.