What's actually being checked
When you log in with a password, the server is not comparing what you typed to a stored copy of your password — or at least it shouldn't be. It is comparing a one-way transform of what you typed to a stored one-way transform of what you originally registered. That transform is a password hash, and the entire defensive story of password authentication is the story of making that hash as expensive to reverse as possible.
The reason matters. A database leak shouldn't leak passwords. It should leak hashes that take attackers years per password to crack. Whether that's true depends entirely on how the hash was computed.
Entropy — the only meaningful strength measure
A password's strength is measured in bits of entropy: roughly, the log2 of how many possible passwords an attacker has to try. Twelve random lowercase letters have ~56 bits. A 6-digit PIN has ~20 bits. "Password1!" has very little; an attacker's dictionary will find it in the first thousand guesses.
The calculator assumes an attacker brute-forcing the full character space — the worst-case for the attacker. Real attackers don't do that. They start with dictionaries, leaked-password lists, and language-model-generated guesses. "correct horse battery staple" has more raw entropy than "9$mQ7vPx2&kL4nR8" only if the attacker doesn't know it's four English words. In 2026, the attacker knows.
The four attack families
Brute Force
Try every possible password from length 1 upward. Mathematically guaranteed to succeed; only the time scales. Modern GPUs hit ~1 trillion guesses/second against fast hashes like unsalted MD5 or SHA-1.
Dictionary
Try the most likely passwords first — words, names, dates, common patterns. RockYou.txt (14 million real leaked passwords, ordered by frequency) is the canonical wordlist. Covers most human-chosen passwords in hours.
Credential Stuffing
Don't crack — just reuse. Take usernames and passwords from another site's breach and try them against yours. Devastatingly effective because 60%+ of users reuse passwords. Doesn't matter how strong yours is if it leaks somewhere else.
Rainbow Tables
Pre-computed lookup tables mapping hashes back to passwords. Trade massive disk for fast lookups. Mostly defeated since 2010 by per-password salts (which force the attacker to build a new table for every account).
The defense stack — what a real password hash looks like
No modern application stores passwords. It stores the output of a password-hashing function — deliberately slow, deliberately memory-hungry, deliberately salted. The cost is borne by the legitimate server once per login. The attacker pays it billions of times.
| Defense | What it does | Defeats |
|---|---|---|
| Salt | Unique random value mixed into each password before hashing. Stored in plaintext alongside the hash. | Rainbow tables. Identical passwords now produce different hashes. |
| Pepper | Server-side secret mixed in addition to the salt. Stored separately from the database (e.g. in an HSM or env var). | Database leaks that don't include the pepper. Defense-in-depth. |
| Slow hash (KDF) | Intentionally expensive function: bcrypt, scrypt, Argon2id. Tunable cost factor. | Brute force. Each guess takes 100–1000ms instead of microseconds. |
| Memory-hard hash | Argon2 and scrypt also burn RAM, not just CPU. Penalizes GPU farms (which have lots of cores but limited memory per core). | GPU/ASIC acceleration. |
| Rate limiting | Cap login attempts per account / per IP / per session. Lockouts, CAPTCHAs, exponential backoff. | Online brute force and credential stuffing. |
| Breach detection | Check entered password against Have I Been Pwned's k-anonymity API. Refuse known-breached passwords at registration. | Credential stuffing of known-bad passwords. |
2026 recommendation: Argon2id with parameters tuned so each hash takes ~250–500ms on your server hardware. Per-password salt. Server-side pepper in an HSM. Rate limiting per account. Refuse passwords that appear in any of the top 10M leaked-password lists.
The hashing hall of shame
- LinkedIn (2012). 117M password hashes stored as unsalted SHA-1. Within days, >90% were cracked. The breach is still being used for credential stuffing.
- Adobe (2013). 153M accounts. Passwords stored encrypted with 3DES — same key for every record — meaning identical passwords produced identical ciphertext. Combined with a leaked password-hint field, >100M were recovered.
- Yahoo (2013, disclosed 2016). 3B accounts, the largest breach ever. Hashes were MD5 with bcrypt only for newer accounts. Older MD5 hashes cracked in bulk.
- Equifax (2017). Not a password breach — SSNs — but worth naming because PII breaches feed credential stuffing too. The downstream effect lasted years.
- Collection #1 (2019). 773M unique email/password pairs aggregated from prior breaches and circulated freely. Most credential-stuffing tooling still ships with a derivative of this list.
Why the rest of this module exists
Every defense above is fighting the same fundamental problem: humans aren't good at picking and remembering high-entropy secrets, and humans reuse the ones they do pick. The other six pages in this module are the layers we have added on top of passwords to compensate. A second factor mitigates reuse. A passkey eliminates the shared-secret problem entirely. SSO reduces the number of credentials a user has to invent. Federation lets one good login do the work of fifty. JWTs are how identity claims travel between systems once the user is authenticated.
The password is not going away. But every authentication system shipped in 2026 should treat it as the weakest credential in the stack, not the only one.