What a strength meter can and cannot tell you
A strength meter reads a string. Whether the password survives depends on something the string does not carry: how it was produced. Almost everything meters get wrong follows from that one gap.
Entropy belongs to the process, not the characters
Type correct horse battery staple into the
strength checker and it prints 165 bits
and the top verdict, Very strong — 28 characters drawn from a pool of 59, since
lower-case letters and the space between words are all it can see.
Now ask where the string came from.
- Drawn as four words from the EFF long list — 7,776 words, so log2(7776) = 12.92 bits per word — it carries 51.7 bits. Against someone who knows the recipe and grinds a stolen fast hash at ten billion guesses a second, that is two days.
- Typed because you read the comic, it carries almost nothing. The phrase has been on cracking wordlists for a decade. It is one guess, and no arithmetic about pools applies to it.
Same 28 characters, different answers, and the meter cannot tell which story it is looking at. The honest way to read its number is as a ceiling: what the password would be worth if every character had been chosen at random.
The common-password list beats the character-class rules
Password123! has an upper-case letter, lower case, a digit and a symbol, and
it is twelve characters long — it satisfies every composition rule an IT policy
has ever printed. Pool arithmetic agrees: 12 × log2(95) = 78.8 bits.
The checker prints 20 bits, Very weak, because the common-password list runs first and caps anything it recognises.
Recognition is not literal matching. The password is checked as typed, as the
stem left when trailing digits and ! @ # $ % . are stripped, and as both of
those with leetspeak undone. So Password1!, Password123! and P@ssw0rd! all reduce to
password, and all three read 20 bits, Very weak: about an hour of online
guessing, instant offline.
The list built into the checker holds 134 entries — the top of the leak rankings for fifteen years, plus the local favourites. That is deliberately small, and it cuts one way only. A flag from it proves the password is bad. Silence from it proves nothing, because a real attacker’s list runs to hundreds of millions of entries with rule engines stacked on top.
Substitution is the first thing an attacker automates
The un-leeting is a fixed table, applied to the lower-cased string: @→a, $→s, 0→o, 1→i, 3→e, 4→a, 5→s, 7→t, !→i. That is not cleverness on the checker’s part; those substitutions are the opening rules in every cracking ruleset, so undoing them is the minimum a meter has to do to see what an attacker sees.
Order matters more than it looks. p@ssw0rd2024 un-leets to password2o2a —
the 0 and the 4 inside the year turn into letters, and no suffix rule can find
a year any more. So trailing digits are stripped both before and after
un-leeting. Fed the whole thing, P@ssw0rd2024! reads 14 bits, flagged as
a known password and as containing a year: one minute of online guessing.
Length against character-set size
Bits are length × log2(pool), and the two inputs do not pull equally.
| Shape | Pool | Bits |
|---|---|---|
| 8 characters, lower case only | 26 | 37.6 |
| 8 characters, full keyboard | 95 | 52.6 |
| 12 characters, lower case only | 26 | 56.4 |
| 12 characters, full keyboard | 95 | 78.8 |
| 16 characters, lower case only | 26 | 75.2 |
| 16 characters, full keyboard | 95 | 105.1 |
Read the first three rows in order. Moving eight lower-case characters to the full keyboard buys 15.0 bits. Adding four more lower-case characters — same alphabet, nothing new to memorise — buys 18.8 bits. Pool size sits inside a logarithm; length multiplies the whole thing.
It is also why Tr0ub4d! and J7#pL2mZ both read 53 bits, Fair. Eight
characters from the full keyboard is eight characters from the full keyboard, as
far as a string can say. One of them was generated and the reading is roughly
right; the other was built from a word, and a dictionary attack with
substitution rules reaches it long before 53 bits would suggest.
The bands the checker prints
| Bits, after penalties | Verdict |
|---|---|
| under 28 | Very weak |
| 28 to 40 | Weak |
| 40 to 60 | Fair |
| 60 to 80 | Strong |
| 80 and above | Very strong |
After penalties is the load-bearing part: a known password caps the total at 20,
a keyboard or alphabet run of four subtracts 10, a character repeated three
times subtracts 8, an embedded year subtracts 6. qwerty123 collects the cap
and the run and lands at 10 bits — five seconds of online guessing.
The two crack times are the same keyspace at two speeds, expected halfway through: a hundred guesses a second against a login that rate-limits, ten billion against a stolen hash on a GPU rig. The offline column assumes a fast unsalted hash. A site storing passwords with bcrypt, scrypt or Argon2 is orders of magnitude slower than that, so read it as a floor rather than a forecast.
What that leaves the meter to do
A password manager generating random strings settles every question above before it is asked. The process is known, so the entropy is known — it is whatever length and alphabet you set in the password generator, and no meter is needed to estimate it. The strength checker exists for the other case: the password a person invented, where the string is the only evidence there is, and the number on the bar is the most optimistic reading of it.