Password hashing simulator

Choose an algorithm and a cost setting. The three steps follow a password through its life. Sign up hashes the password with a fresh random salt and shows the string a database would store, and how long that took on your device. Log in checks an attempt the way a server does, by hashing it again with the stored salt and settings. The database leaks builds a table of six users, hashed with the current settings, and runs a dictionary attack on it: every word of a 100-word list is tried against every user.

All the hashing is real. SHA-256 and PBKDF2 use your browser’s Web Crypto API; bcrypt, scrypt and Argon2id use the hash-wasm library. The outputs match Python’s hashlib, bcrypt and argon2-cffi for the same inputs. Things to try:

• Attack the table with SHA-256. It finishes almost instantly, and alice and dave have the same hash, so cracking one cracks both.
• Switch to SHA-256 + salt. The hashes differ, and the attack does 6 times the work, but it is still fast.
• Switch to Argon2id or bcrypt cost 12 and run the attack again. Watch the rate. erin’s password is not on the list, so no setting reveals it.

Password hashing is how a system checks passwords without keeping them. When a user signs up, the server runs the password through a one-way function and stores the result. When they log in, it runs what they typed through the same function and compares. The server never needs the password itself, so it never stores it.

The threat it defends against is a leak of the database, through a bug, a stolen backup or an insider. Hashes cannot be reversed, but they can be guessed: an attacker hashes candidate passwords and looks for matches. Since people reuse passwords, every cracked one is a risk to the user’s other accounts too. Good password hashing does not make guessing impossible. It makes each guess expensive, so that only weak passwords fall, and slowly.

That is why password hashing functions are different from ordinary hash functions. They take a salt, so equal passwords give different results, and a cost setting, so they can be made as slow as the login server can afford.

MD5, SHA-1 and SHA-256 are designed to be fast, which is what you want for checking file downloads and what an attacker wants for guessing passwords. Graphics cards compute them in parallel at enormous rates. A published hashcat v6.2.6 benchmark on a single NVIDIA RTX 4090 gives these speeds:

Without a salt, the same password always gives the same hash. That has two consequences, both visible in the simulator. Users with the same password have the same hash, so cracking one cracks all of them, and the attacker can see who shares a password before cracking anything. And an attacker can compute the hashes of common passwords once and reuse them against every leaked database. Lookup tables and their compressed form, rainbow tables (Philippe Oechslin, 2003), store exactly that.

A salt is a random value generated for each password when it is set, typically 16 bytes, hashed together with the password and stored next to the hash. It does not need to be secret. Because each user’s salt is different, precomputed tables are useless and every guess has to be hashed separately for every user. In the simulator, the salted attack computes up to 6 times as many hashes as the unsalted one.

A salt alone does not make a fast hash safe. Salted SHA-256 still runs at billions of guesses per second per user; the salt only stops the attacker from sharing work between users. It has to be combined with a slow function.

The answer to fast hardware is key stretching: repeat the work so that one hash takes a noticeable time. A user logging in waits a few hundred milliseconds once; an attacker trying billions of guesses waits a few hundred milliseconds billions of times, divided only by how much hardware they have.

PBKDF2 (password-based key derivation function 2, from PKCS #5, now RFC 8018) applies HMAC with a hash such as SHA-256 thousands of times. It is simple, standardised and available almost everywhere, including in FIPS-140 validated libraries, which is why it is still common. Its weakness is that it needs almost no memory, so GPUs run it efficiently.

bcrypt, by Niels Provos and David Mazières (USENIX 1999), is built on the Blowfish cipher’s expensive key setup, repeated 2^cost times, so each increase in the cost doubles the time. It uses 4 KiB of fast-changing memory, which made it awkward for GPUs, and it has held up well for over two decades. Two limits matter in practice: bcrypt only uses the first 72 bytes of the password, and some implementations stop at a zero byte, which is why pre-hashing the password with a fast hash before bcrypt needs care.

GPUs and custom chips are good at arithmetic and comparatively poor at memory: each core has little of it. A memory-hard function forces each guess to fill and read a large block of memory, so an attacker running many guesses in parallel needs that much memory for each one. Time is no longer the only cost; memory is too.

scrypt, designed by Colin Percival in 2009 for the Tarsnap backup service and standardised as RFC 7914, has three parameters: N, the memory and time cost (a power of two), r, the block size, and p, the parallelism. It uses about 128 × N × r bytes, so N = 2¹⁷ with r = 8 needs 128 MiB.

Argon2, by Alex Biryukov, Daniel Dinu and Dmitry Khovratovich, won the Password Hashing Competition in 2015 and is standardised as RFC 9106. Its memory cost (m, in KiB), time cost (t, the number of passes over the memory) and parallelism (p) are set separately. There are three variants: Argon2d resists GPU attacks best but its memory access depends on the password, which can leak through side channels; Argon2i avoids that; Argon2id combines the two and is the one to use for passwords.

In the simulator, Argon2id and scrypt run in WebAssembly in a single thread, which is slower than native code on a server. The comparison between them and the fast hashes is still fair in proportion.

The OWASP Password Storage Cheat Sheet recommends, in order: Argon2id; scrypt if Argon2id is not available; bcrypt for legacy systems; and PBKDF2 where FIPS-140 compliance is required. The simulator includes its minimum settings alongside some older ones:

Modern libraries store everything needed to check a password in one string: the algorithm, its version, the parameters, the salt and the hash. An Argon2id hash in the PHC string format looks like this:

• Pepper. A secret value shared by all passwords and stored outside the database, for example in a secrets manager or a hardware security module. Mixing it in (or encrypting the hashes with it) means a leaked database alone is not enough to start guessing. It adds defence in depth on top of a salted slow hash.
• Upgrading. On each successful login, check whether the stored hash uses old settings and, if so, rehash the password the user just typed. For accounts that never log in, wrap the old hash in the new function, for example Argon2id(SHA-1(password)), and mark the record.
• Comparing. Compare hashes in constant time, so that response times do not reveal how many leading bytes matched. Library verify functions do this.
• Do not roll your own. Use the password hashing functions of a maintained library (libsodium, the language’s standard bcrypt or Argon2 binding) rather than combining primitives yourself.
• Do not encrypt. Encrypted passwords can all be recovered by anyone who gets the key.
• Length limits. Allow long passwords, but cap the length (for example at a few hundred characters) so a huge input cannot be used to tie up the server; with bcrypt, account for its 72-byte limit.

Real breaches show each mistake. LinkedIn’s 2012 breach exposed passwords stored as unsalted SHA-1 hashes, which were then cracked in large numbers. Adobe’s 2013 breach exposed passwords that were encrypted with 3DES in ECB mode rather than hashed, so equal passwords had equal ciphertexts and were stored next to users’ password hints. Ashley Madison (2015) hashed passwords with bcrypt at cost 12, but researchers found millions of accounts that also stored an MD5-based token derived from the username and lowercased password, and cracked those instead. A strong hash does not help if a weak copy of the same secret sits next to it.

“How would you store passwords?” is a common question in backend and security interviews. A complete answer covers: never store or log plain passwords; use a slow, salted, memory-hard function (Argon2id, or bcrypt with a cost of at least 10); a unique random salt per password, stored with the hash; parameters stored with the hash so they can be raised later; constant-time comparison; rate limiting and lockouts on login; optionally a pepper kept outside the database; and a plan to rehash on login when settings change.

Follow-ups often ask why not SHA-256 (speed, as the table above shows), what a rainbow table is and why salts defeat it, and the difference between hashing and encryption.