Password strength is entropy, and entropy is log2(pool^length) — the number of bits needed to describe one password drawn at random under a given rule. Twenty random lowercase letters give about 94 bits. Eight characters of mixed case, digits and symbols give about 52. Length multiplies inside the exponent while the character pool only multiplies the base, which is why length wins so decisively.
That single comparison overturns most password policies written in the last thirty years.
What do common rules actually buy?
Two policies that sound similar can differ enormously.
| Rule | Pool | Entropy |
|---|---|---|
| 8 chars, lower case only | 26 | ~38 bits |
| 8 chars, mixed case + digits | 62 | ~48 bits |
| 8 chars, all printable | 95 | ~53 bits |
| 12 chars, lower case only | 26 | ~56 bits |
| 16 chars, lower case only | 26 | ~75 bits |
| 20 chars, lower case only | 26 | ~94 bits |
Twelve plain lowercase letters already beat eight characters of everything. Adding four more characters is worth more than adding every symbol on the keyboard, and it is far easier to type on a phone.
Why is a strength meter an upper bound?
Because it measures the entropy of the generator, not of the string. A meter reads the character classes present and the length and reports what a random password under those rules would be worth — it cannot know whether yours was random.
"Password1!" contains four character classes and ten characters, and a naive meter scores it well. It is also in every cracking dictionary ever assembled, so its real strength is close to zero. The meter is not lying; it is answering a question about rules rather than about your specific choice.
That is the whole argument for generating rather than inventing. A generated password is the random draw the meter assumes, which makes the number meaningful rather than aspirational.
Are passphrases weaker?
No, provided the words are chosen randomly. Each word contributes log2(list size) bits — from a 7,776-word list that is 12.9 bits per word, so six words give about 77 bits and seven give 90.
The strength comes entirely from the randomness of the choice, not from the words. A phrase you thought of is worth far less than its length suggests, because human word choice is heavily predictable and the space of memorable phrases is much smaller than the space of word combinations.
The practical case for passphrases is the handful of passwords you have to type from memory — a device unlock, a password manager master key. Everything else should be a long random string you never see, stored in a manager.
What about PINs?
They are weak by construction and that is usually acceptable. A four-digit PIN has ten thousand possibilities, which is fine when something limits the number of attempts and useless when nothing does.
The reason to generate rather than choose is that human PINs cluster hard. Analyses of leaked PIN sets repeatedly find that a small handful — 1234, 1111, 0000, and year-shaped numbers beginning 19 or 20 — account for a substantial share of all PINs in use.
A generated PIN is one of ten thousand. A chosen one is frequently one of about twenty.
What does an attacker actually do?
Not brute force, in almost every real case. Credential stuffing — trying username and password pairs leaked from one service against another — costs nothing and works because reuse is common, and no amount of entropy in a reused password helps.
After that comes the dictionary attack with rules: take a wordlist, apply the substitutions people actually make — a to @, o to zero, a digit and a symbol on the end — and try the result. That is why "Password1!" fails instantly despite scoring well on a naive meter: it is one rule applied to one of the commonest words in the list.
Genuine brute force is the last resort and the one the entropy figure describes. It is the attack that matters least in practice and the only one the number is measuring.
How long should a machine secret be?
A hundred and twenty-eight bits, from a cryptographic source. A token is read by software rather than typed by a person, so it can be long and ugly, and the only things that matter are the entropy and the source.
| Encoding | Bits per character | Suits |
|---|---|---|
| Hex | 4 | Universally safe, wastes space |
| Base32 | 5 | Survives being read aloud or typed |
| Base64url | 6 | Compact and URL-safe |
TOTP secrets are a specific case: 160 random bits, base32-encoded without padding, delivered in a URI whose defaults — SHA-1, six digits, a thirty-second period — look dated and are what RFC 6238 specifies. Deviating from them breaks compatibility with most authenticator apps for no security gain that matters at this scale.
Questions people ask
How many bits are enough? Around 80 for something rate-limited, 128 for anything an attacker can attack offline. Above 128 the arithmetic stops being the weak point long before the number does.
Do forced periodic changes help? Current guidance from major standards bodies says no — they push people toward predictable variations of one password. Change on evidence of compromise, not on a calendar.
Should I use symbols at all? They add a little and they cost compatibility with systems that reject them. Length is the cheaper way to buy the same strength.
Is a password manager a single point of failure? Yes, and it is a much better one than reusing passwords across sites. The failure mode it removes is far more common than the one it introduces.
Length sits in the exponent, which is why nothing else comes close. The password generator and passphrase generator do the drawing, the entropy calculator and strength checker explain what a policy is worth, and the PIN, token and TOTP secret generators cover the shorter secrets with narrower jobs.