Password Entropy: The Real Math Behind Why Length Beats Complexity
Password advice has been stuck for two decades on some version of “use uppercase, lowercase, a number, and a symbol.” The math says that’s mostly wrong — or at least badly prioritized. The strength of a randomly generated password is governed by a single formula, and that formula rewards length far more aggressively than it rewards a bigger character set. This is also, not coincidentally, what NIST has been saying since SP 800-63B (2017, revised 2024).
This article walks through the actual math, computes real entropy values, gives brute-force estimates with explicitly stated assumptions, and then translates it into rules you can apply.
The entropy formula
For a password drawn uniformly at random from a character pool of size P, with length L, the number of possible passwords is P^L, and the entropy in bits is:
H = log2(P^L) = L × log2(P)That’s the whole model. Entropy measures the size of the search space an attacker must enumerate. Every additional bit doubles the work.
The two levers are P (pool size) and L (length), and they are not equal. Adding one character multiplies the search space by P; widening the pool multiplies it by a ratio. Here are the pools that matter and their per-character entropy contributions:
| Character pool | Size (P) | Bits per character, log2(P) |
|---|---|---|
Digits only (0–9) | 10 | 3.32 |
Lowercase letters (a–z) | 26 | 4.70 |
Lower + uppercase (a–zA–Z) | 52 | 5.70 |
Alphanumeric (a–zA–Z0–9) | 62 | 5.95 |
| Full printable ASCII (94 chars incl. symbols) | 94 | 6.55 |
Note the diminishing returns on pool expansion: going from lowercase-only (26) to the full printable set (94) nearly quadruples the pool but only raises per-character entropy from 4.70 to 6.55 bits — a 39% gain per character. Going from 8 characters to 16 at any pool size exactly doubles the entropy. Length scales linearly with no ceiling; pool size is capped at ~94 on a standard keyboard.
Real entropy values, computed
Applying H = L × log2(P):
Full printable ASCII pool (94 chars):
| Length | Entropy (bits) | Search space |
|---|---|---|
| 8 | 52.4 | ~6.1 × 10^15 |
| 10 | 65.5 | ~4.4 × 10^19 |
| 12 | 78.7 | ~4.8 × 10^23 |
| 14 | 91.8 | ~5.1 × 10^27 |
| 16 | 104.9 | ~3.7 × 10^31 |
| 20 | 131.1 | ~2.9 × 10^39 |
Lowercase-only pool (26 chars):
| Length | Entropy (bits) |
|---|---|
| 8 | 37.6 |
| 12 | 56.4 |
| 16 | 75.2 |
| 20 | 94.0 |
Alphanumeric pool (62 chars):
| Length | Entropy (bits) |
|---|---|
| 8 | 47.6 |
| 12 | 71.5 |
| 16 | 95.3 |
| 20 | 119.1 |
Now the comparison that makes the point. Look at these three passwords, all plausible outputs of different policies:
xQ9#mK2!— 8 chars, full 94-char pool: 52.4 bitshkbwvztdpqrm— 12 chars, lowercase only: 56.4 bitshkbwvztdpqrmjfyc— 16 chars, lowercase only: 75.2 bits
The “simple” 12-character lowercase password already beats the “complex” 8-character one, and the 16-character lowercase password beats it by 23 bits — a factor of about 8 million in search space — while being dramatically easier to type and remember. Four extra characters are worth more than the entire symbol set.
This is the sense in which length beats complexity: not that complexity is worthless (a wider pool always helps at fixed length), but that humans are terrible at producing complexity randomly, and the marginal entropy per added character exceeds the marginal entropy per pool widening for any realistic pool.
The giant caveat: this only works for random passwords
The formula H = L × log2(P) assumes a uniform random draw. Human-chosen passwords are nothing of the sort. Summer2026! is 11 characters from a ~90-char pool — nominally ~71 bits — but any cracking tool tries it within its first few thousand guesses because it’s a dictionary word, a year, and the most common symbol, in the most common arrangement.
Human password entropy is dominated by predictability, not by the formula. Empirical analyses of breached password corpora consistently find that a small dictionary of common passwords plus mangling rules (capitalize first letter, append digits, append !) covers a large fraction of real passwords. That’s why:
- Entropy math applies to generated passwords, passphrases from wordlists, and manager-created secrets — not to anything a person invents unaided.
- For human-chosen passwords, the defense isn’t entropy estimation, it’s screening against known-breached and common-password lists — which is exactly what NIST mandates.
Passphrases and Diceware
The Diceware method makes the math concrete for memorable secrets: roll dice to pick words uniformly from a 7,776-word list (6^5). Each word carries log2(7776) ≈ 12.9 bits:
- 5 words: 64.6 bits
- 6 words: 77.5 bits
- 7 words: 90.4 bits
A 6-word passphrase like correct horse battery staple-style (the famous XKCD example illustrates the same math) gives ~77 bits with far better memorability than a random 12-character string at 78.7 bits. Same security tier, wildly different usability.
Brute-force time estimates — with the assumptions stated
Any “time to crack” number is meaningless without its attack model. Here is one, stated explicitly:
Assumptions: offline attack against a fast, unsalted hash (e.g., raw MD5/SHA-1) at 10^10 (10 billion) guesses per second — achievable with a modest multi-GPU rig. Exhaustive search of the full space; expected time to find the password is half that. No throttling, no breach list shortcuts (valid because we assume random passwords).
| Password class | Search space | Exhaustive time @ 10^10/s |
|---|---|---|
| 8 chars, lowercase (26) | 2.1 × 10^11 | ~21 seconds |
| 8 chars, full pool (94) | 6.1 × 10^15 | ~7 days |
| 12 chars, lowercase (26) | 9.5 × 10^16 | ~110 days |
| 12 chars, full pool (94) | 4.8 × 10^23 | ~1.5 million years |
| 16 chars, lowercase (26) | 4.4 × 10^22 | ~140,000 years |
| 16 chars, full pool (94) | 3.7 × 10^31 | ~1.2 × 10^14 years |
Treat these as illustrative orders of magnitude, not guarantees. They shift in both directions:
- Slower in practice if the site uses a proper password hashing function. bcrypt, scrypt, or Argon2 with sane parameters can reduce guessing throughput by 4–7 orders of magnitude compared to raw MD5, turning “~7 days” into “longer than the heat death schedule anyone cares about.” This is why hashing algorithm choice matters more than almost anything users do.
- Faster if the password isn’t random (dictionary attack), the attacker has nation-state hardware, or Moore’s-law-style improvements compound over the years a stolen hash remains valuable.
- Online attacks (guessing against a live login endpoint) are a different model entirely: rate limits and lockouts cap attackers at perhaps hundreds of guesses, so even ~20-bit secrets survive — this is why NIST requires throttling, and why your password manager’s per-site passwords matter more than any single password’s strength.
The practical takeaway from the table: 8 characters is not enough for anything that will be hashed fast, full stop; 12+ random characters is comfortable; 16 is overkill in the good way. And again, the 16-char lowercase string outlasts the 12-char full-pool string — length wins.
What NIST SP 800-63B actually says
NIST’s Digital Identity Guidelines (SP 800-63B, originally 2017; Revision 4 published 2024) codified much of this into US federal policy. The load-bearing recommendations for password (“memorized secret”) verifiers:
- Minimum length, not complexity. Require at least 8 characters for user-chosen passwords (Revision 4 raises this to 15 for passwords used as a single factor, 8 when a second factor is present). Allow at least 64 characters. Do not impose composition rules (no “must contain uppercase, digit, symbol”) — they push users toward predictable patterns (
Password1!) that weaken real-world security. - No forced periodic changes. The 2017 revision already dropped the old “rotate every 90 days” dogma; Revision 4 reaffirms it. Change passwords only when there’s evidence of compromise. Forced rotation reliably produces
Summer2026!→Autumn2026!— an increment a cracking rule covers trivially. - Screen against breached and common-password lists. Verifiers should compare candidate passwords against dictionaries of known-compromised passwords, dictionary words, repetitive/sequential strings, and context-specific words (the service name, the username). This replaces composition rules as the real defense for human-chosen secrets.
- Allow paste and password managers. Verifiers must permit pasted input — which is an explicit endorsement of password managers, since generated 20-character random strings are exactly what the guidelines want users to have.
- No knowledge-based hints or security questions. Password hints and KBA (“mother’s maiden name”) are prohibited as they leak or trivially reveal the secret.
- Salted, memory-hard hashing for storage. Verifiers must store passwords hashed with a suitable one-way function — the guidance points to schemes like Argon2, bcrypt, or PBKDF2 with adequate work factors — with a per-user salt of at least 32 bits.
Notice how these cohere with the entropy math: composition rules don’t add real entropy for humans, length does; rotation destroys whatever entropy users had by pushing them to patterns; and the breached-list screen handles the fact that human entropy is unmeasurable. The standard is the math, institutionalized.
Rules you can actually use
- Let a generator make your passwords. Random generation is the only way the entropy formula applies to you. Our Password Generator creates cryptographically random passwords in your browser — nothing is transmitted anywhere. Set it to 16+ characters and stop thinking about it.
- Default to 16 characters for anything important. At 95+ bits even for lowercase-only, you’re beyond any conceivable brute-force budget against a properly hashed store.
- For things you must memorize, use a 6-word passphrase. ~77 bits, typeable, rememberable. Generate candidates with the same tool’s passphrase/wordlist mode if available, or use Diceware.
- Unique per site, always. Entropy protects one site; reuse converts one breach into every breach. This is what the password manager is for.
- Add a second factor where offered. NIST’s length requirements explicitly relax when MFA is present, because a second factor multiplies attacker work far more cheaply than more password entropy.
- Ignore complexity theater. A site demanding “one uppercase, one digit, one symbol” but capping you at 12 characters has the policy backwards. Comply mechanically, but don’t mistake it for strength.
Summary
- Random-password entropy is
H = L × log2(P): every character adds a fixed number of bits depending only on pool size. - Pool widening (26 → 94 chars) gains ~1.85 bits per character; each added character gains 4.7–6.6 bits. Length wins decisively.
- 8 random characters ≈ 52 bits ≈ days-to-crack against fast offline hashes; 12 random characters ≈ 78+ bits ≈ effectively uncrackable in that model.
- The formula only applies to random generation. Human-chosen passwords are defeated by dictionaries, which is why NIST mandates breached-list screening and bans composition rules and forced rotation.
- Generate 16-character random passwords with the Password Generator, store them in a manager, and enable MFA. That stack is what the math recommends.