security
Password Entropy Explained: Why Strength Meters Disagree
The entropy formula every strength meter starts from, why it overrates human-chosen passwords, how zxcvbn-style estimators differ, and the real math behind diceware and BIP39 passphrases.
Type the same password into three different strength meters and you can get three different verdicts — “Strong,” “Fair,” and “This would be cracked instantly.” That’s not because two of them are broken. It’s because “password entropy” is a measure of the process that generated a password, not of the string itself — and each meter is guessing at a different process.
Once you see what each kind of meter assumes, the disagreements stop being mysterious, and you can tell which number applies to your password.
The naive formula
The calculation almost every meter starts from is simple. If a password is built by picking L characters uniformly at random from a pool of N possibilities, the number of equally likely passwords is N^L, and the entropy in bits is:
E = L × log2(N)Each character contributes log2(N) bits, because that’s how many yes/no questions an attacker would need to pin one character down. The pool sizes for common character sets:
| Character set | Pool size (N) | Bits per character |
|---|---|---|
| Lowercase only | 26 | 4.70 |
| Upper + lowercase | 52 | 5.70 |
| Letters + digits | 62 | 5.95 |
| Full printable ASCII | 95 | 6.57 |
| EFF long wordlist (per word) | 7,776 | 12.92 |
| BIP39 wordlist (per word) | 2,048 | 11.00 |
Worked examples, with average-case offline crack time at 10 billion guesses per second (an attacker searching half the space before hitting the answer):
| Password type | Calculation | Entropy | Avg. offline crack time @ 10¹⁰/s |
|---|---|---|---|
| 8 chars, lowercase | 8 × 4.70 | ~37.6 bits | ~10 seconds |
| 10 chars, letters + digits | 10 × 5.95 | ~59.5 bits | ~1.3 years |
| 12 chars, full ASCII | 12 × 6.57 | ~78.8 bits | ~800,000 years |
| 5 random EFF words | 5 × 12.92 | ~64.6 bits | ~44 years |
| 6 random EFF words | 6 × 12.92 | ~77.5 bits | ~340,000 years |
Those crack times follow directly from the bits — every extra bit doubles the search. And the table already shows the trade passphrases make: a six-word phrase is far longer to type than kV#9m!qR2$xz, but it lands in the same entropy range while being memorable.
There’s one enormous caveat, and it’s the whole story.
Why the formula lies about human-chosen passwords
E = L × log2(N) is only valid if every character was drawn uniformly at random. Humans don’t do that. We pick a word, capitalize the first letter, swap an a for @, and append 1!.
Take P@ssw0rd1!. Pool math sees 10 characters drawn from all four character classes: 10 × 6.57 ≈ 66 bits — solidly “Strong” on any naive meter. But no attacker searches for it character by character. Real cracking tools take a dictionary and apply mangling rules — capitalize first letter, common l33t substitutions, append digits and punctuation. Under that model, P@ssw0rd1! is one of the very first things tried: a top-10 base word with three of the most common rules applied. The 66 bits were never there, because the process that produced the password had almost no randomness in it.
This is precisely why meters disagree. There are two families:
- Pool-math meters compute
L × log2(N)from the characters present, sometimes with penalties for obvious patterns. They answer: “how strong would this be if it were random?” - Pattern-based estimators, of which zxcvbn (built at Dropbox) is the best known, attack the password the way a cracker would. zxcvbn tries to decompose the string into chunks it recognizes — dictionary words (with rank:
passwordis cheaper thanossify), l33t substitutions, dates, years, repeats, sequences, and keyboard walks likeqwaszx— then finds the cheapest decomposition and reports the estimated number of guesses to reach it.P@ssw0rd1!decomposes into a top-ranked word plus common transforms, so zxcvbn prices it at a tiny fraction of what pool math claims.
Neither family is “correct.” A pool-math meter is exactly right for machine-generated passwords and wildly optimistic for human-chosen ones. A zxcvbn-style estimator is much more realistic for human-chosen passwords, but it can only recognize patterns in its dictionaries — it’s a lower-bound-flavored estimate, not a guarantee.
What our meter actually does
In the interest of the honesty this post is asking of everyone else: our password strength analyzer is a pool-math meter with pattern penalties, not a zxcvbn-style decomposer. Concretely, from the source:
- It detects which character classes you used (26 lowercase, 26 uppercase, 10 digits, 33 symbols) and computes
length × log2(pool). - It multiplies the result by 0.7 if it finds repeated runs (
aaa) and by 0.7 again for ascending sequences (abc,123). - A shortlist of the most common passwords (
password,123456,qwerty, …) is scored zero and reported as crackable instantly. - Crack time assumes an offline attack at 10¹⁰ guesses/second, searching half the keyspace on average. Scores map to entropy bands: under 28 bits is Very Weak, 28–40 Weak, 40–60 Fair, 60–80 Strong, 80+ Very Strong.
That means our meter will overrate a cleverly mangled dictionary word — P@ssw0rd1! scores about 66 bits and “Strong” here, and it should not be trusted at that. It will also overrate a passphrase for the wrong reason: it counts a five-word phrase as ~30 characters of mixed pool rather than 5 draws from a wordlist, reporting far more bits than the generation process actually contains. The number it reports is trustworthy in exactly one case: when the password was generated randomly, like the output of our password generator, which draws every character from crypto.getRandomValues. For random output, pool math is not an estimate — it’s the definition.
Passphrases: the XKCD 936 argument, stated precisely
The famous XKCD “correct horse battery staple” comic is frequently misquoted as “four words beats a complex password.” The actual claim is narrower and it matters:
A passphrase of words selected uniformly at random from a known wordlist has entropy of
words × log2(wordlist size)— even if the attacker knows the wordlist, the word count, and the method.
The entropy comes from the random selection, not from the attacker being unaware you used words. This is Kerckhoffs’s principle applied to passwords: assume the method is public; only the random choices are secret. The flip side is the common failure mode — four words you thought of are not four random words. Human word choice is heavily skewed toward common, thematically related words, and its entropy is far below 11–13 bits per word.
The standard way to get genuinely random words is diceware: roll five dice per word and look up the result in the EFF long wordlist, which has exactly 6⁵ = 7,776 words — log2(7,776) ≈ 12.9 bits per word. EFF’s own worked example confirms the math: a six-word passphrase is “one of about 2⁷⁷ alternatives,” i.e. 6 × 12.9 ≈ 77.5 bits.
The same construction shows up in cryptocurrency wallets. A BIP39 mnemonic draws from a fixed list of 2,048 words — exactly 11 bits per word. A 12-word mnemonic encodes 128 bits of entropy (the remaining 4 bits are a checksum); a 24-word mnemonic encodes 256 bits plus an 8-bit checksum. Our BIP39 generator produces and validates these, checksum included, entirely in your browser.
Crack time is about the hash, not just the password
Every crack-time figure hides an assumption: guesses per second. That number varies by roughly eight orders of magnitude depending on how the target stores passwords.
In an offline attack — the attacker has stolen a database of password hashes — speed is set by the hash function. A single modern GPU computes fast hashes like MD5 or NTLM on the order of 10¹¹ per second. The same GPU manages bcrypt at a typical cost factor of 12 on the order of 10³ per second, because bcrypt is deliberately expensive and doubles in cost with each increment (here’s how bcrypt works). That gap — about a factor of 10⁸ — is worth roughly 27 bits of entropy (log2(10⁸) ≈ 26.6). Storing passwords with a slow hash is equivalent to making every user’s password five random characters longer, at zero cost to users.
An online attack — guessing through the login form — is a different regime entirely. The server enforces rate limits, lockouts, and CAPTCHAs; an attacker might manage tens of guesses per second against one account, not billions. A password that survives online guessing can still fall in minutes offline. This is why breach disclosures matter so much: the moment hashes leak, every password’s effective strength is re-measured against offline speeds.
The same reasoning governs password-derived encryption keys, where the iteration count of the KDF is the tunable that sets guesses per second — see what “AES encrypt” actually does in your browser for what that costs in milliseconds and why it’s hard to raise after the fact.
The honest summary: a crack-time readout (including ours) is a unit conversion of entropy under stated assumptions, not a prophecy. Change the hash or the hardware and the number moves by orders of magnitude.
What NIST actually says now
NIST SP 800-63B (Revision 4, finalized in 2025) is the US federal guideline for password handling, and it reads like a repudiation of 2000s-era policy. The normative requirements for verifiers:
- Length over complexity. Passwords used as a single authentication factor “SHALL … be a minimum of 15 characters in length”; passwords used within multi-factor authentication may be shorter but must be at least 8. Maximums must allow at least 64 characters.
- No composition rules. Verifiers “SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types).” Mandatory symbol-and-digit checklists are out.
- No scheduled rotation. Verifiers “SHALL NOT require subscribers to change passwords periodically” — but “SHALL force a change if there is evidence that the authenticator has been compromised.”
- Blocklist screening. Verifiers “SHALL compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords.”
Note these rules constrain what verifiers may demand, which is a different question from what makes an individual password strong — adding character classes to a randomly generated password genuinely does add bits. NIST’s point is that forcing composition on humans produces predictable transformations (Password1!) instead of entropy, while length and breach screening actually work.
Try it
- Password Strength Analyzer — pool-math entropy in bits with pattern penalties and offline crack-time estimates, computed locally. Trust it fully for random passwords; treat it as an upper bound for human-chosen ones.
- Password Generator — cryptographically random passwords where the entropy math genuinely applies.
- BIP39 Mnemonic Generator — 12–24 word mnemonics at exactly 11 bits per word, with checksum validation.