Password entropy: why complexity rules backfire

"At least eight characters, with one uppercase letter, one number and one special character." It is the most widespread password rule in the world, and one of the least effective: it produces passwords that are hard for people to remember and easy for machines to guess. The reason lies in a concept that rule fails to capture — entropy.

This article explains what password entropy actually measures, why it is not a property of the string you are looking at, and what the numbers say once you stop reasoning by intuition.

Entropy measures the process, not the string

This is the point that reframes everything else. You cannot compute entropy by looking at a password: you compute it by knowing the process that produced it. Two identical passwords can have completely different entropy depending on how they came to exist.

Take the string Sunset7!. If a random generator produced it over a 95-character printable alphabet, that is eight characters at 6.57 bits each, about 53 bits. If instead a person chose it — starting from a common word, capitalising the first letter because the form demands it, appending a digit and an exclamation mark because the form demands those too — then the real search space is not 95^8. It is "common English word, capitalised, plus a digit, plus a symbol". An attacker who knows that pattern, and they do because almost everyone follows it, works through a few tens of millions of combinations. Hours, not geological ages.

The formula

For a password built by picking each character independently and uniformly from an alphabet of N symbols, L characters long, entropy in bits is:

H = L × log₂(N)

N = 26   (lowercase only)        → 4.70 bits per character
N = 52   (upper + lower)         → 5.70 bits per character
N = 62   (alphanumeric)          → 5.95 bits per character
N = 95   (printable ASCII)       → 6.57 bits per character

Every bit of entropy doubles the attacker's work. Ten more bits mean a thousand times more attempts; twenty more bits, a million times. This is why making a password longer buys far more than enriching its alphabet: length multiplies, the alphabet does not.

What a bit is worth, in time

Bits become concrete when multiplied by an attack rate. That rate depends almost entirely on a choice the user does not control: the function the service used to store the password. With MD5, a modern GPU tries on the order of a hundred billion combinations per second; with bcrypt at cost 12, a few tens of thousands.

Why composition rules fail

Forcing an uppercase letter, a digit and a symbol appears to widen the available alphabet, and in theory it does. In practice it lowers real entropy, because people satisfy the constraint in the same way as each other.

• The uppercase letter goes first. Almost always.
• The digit goes last, and it is almost always 1, or a recent year, or a birth date.
• The symbol follows the digit, and it is ! in the large majority of cases.
• "Clever" substitutions — a→@, e→3, o→0, s→$ — have been in attack dictionaries for twenty years: they are a zero-cost transformation for the attacker.

So a constraint meant to widen the search space ends up concentrating it. An attacker does not try every possible combination: they try the likely ones first, and composition rules tell them exactly which those are. Then there is the collateral damage: harder-to-remember passwords drive reuse across services, and reuse is the real risk multiplier, because one breach elsewhere becomes access to everything.

Passphrases

The alternative is to change the unit: random words instead of random characters. With a 7,776-word list — the classic diceware size, five rolls of a six-sided die per word — each word is worth log₂(7776), that is 12.92 bits.

Six random words give 77.5 bits and are visually memorable; twelve random ASCII characters give 78.8 bits and are not memorable at all. The constraint, again, is that the words must be drawn at random from a list: a sentence that makes sense, taken from a song or invented by you, is not a passphrase — it is a phrase, and phrases are in dictionaries.

What modern guidance says

Official recommendations have moved in the same direction. The NIST digital identity guidelines, revised on exactly this point, abandoned the traditional posture:

• No mandatory composition rules: do not require uppercase, digits or symbols.
• No arbitrary periodic expiry: rotating passwords every ninety days makes user choices worse, as they end up incrementing a counter. Rotate when compromise is suspected.
• A sensible minimum and a generous maximum: at least eight characters, preferably fifteen, and accept at least sixty-four.
• Accept every character, spaces and emoji included. Every forbidden character is entropy handed to the attacker.
• Screen new passwords against known-breached lists: the best effectiveness-to-cost ratio of any check available.
• Drop security questions. The answers are often public on social media.

In practice

If you use passwords: use a password manager and let it generate long random strings, different for every service. The only password you need to remember is the manager's, and that one is best made a six or seven word random passphrase. Turn on two-factor authentication wherever it is offered: it adds a factor that cannot be guessed from someone else's stolen database.

If you store passwords: use a deliberately slow hash — Argon2id, scrypt or bcrypt — with a random per-user salt, and tune the cost to current hardware. Do not invent anything in-house. And when you collect a new password, check it against breached-credential lists instead of demanding one more symbol: the first check blocks real attacks, the second only produces passwords that end up on a sticky note.