Password Entropy: What a Strength Meter Cannot Know

Entropy belongs to the generator, not to the string

Ask how much entropy the string correct-horse-battery-staple has and the question is already malformed. If four words were drawn with dice from a published 7,776-word list, the answer is 51.70 bits. If someone read them in a famous comic strip and typed them in, the answer is close to zero, because an attacker's very first guesses will include exactly that phrase. Same characters, same length, same character classes — completely different security, because entropy measures how many equally likely outcomes the process could have produced, and the string cannot tell you what the process was.

This is why the whole discipline talks about generated passwords. A password manager that draws from a cryptographic random source knows R and L, so it can state the entropy exactly. A human at a keyboard does not have a well-defined R, because human choices are not uniform: certain letters, certain substitutions, certain years and certain keyboard patterns are far more likely than others, and every serious cracking tool is built around exactly that skew. Any figure attached to a human-chosen password is a guess about how well an attacker's model matches that human's habits.

The formula, and the condition attached to it

H = L x log2(R). The logarithm converts a count of possibilities into bits, and multiplying by length works because each independent draw adds its own bits. log2(94) = 6.5546, so every extra random printable ASCII character adds 6.5546 bits. log2(26) = 4.7004, so a lowercase letter adds fewer. log2(7,776) = 12.9248, so one Diceware word adds nearly twice what a random character does — 7,776 is 6^5, five dice throws, which is why the list is that exact size.

The condition is uniform independent random selection, and it is doing all the work. Break it and the formula silently stops applying while still returning a comfortable number. Choose a word you like instead of rolling dice: R is no longer 7,776. Capitalise the first letter because a policy demands it: the capital adds no entropy at all, because everyone does the same thing. Append an exclamation mark and a year: those characters lengthen L on paper while an attacker's rule set generates them for free. The formula does not know any of that. It was never told what the process was.

There is a third quantity that gets tangled up with these two, and it is worth separating. Shannon entropy of a string, the thing a general entropy calculator computes, measures the distribution of symbols inside that particular string. For P@ssw0rd123! it comes to 3.4183 bits per character, because some characters repeat. That number is genuinely useful for compression and for spotting encrypted blobs, and it says nothing at all about how hard the password is to guess. Three different questions, three different numbers, and confusing them is the origin of a great deal of bad advice.

What the meter is actually measuring

The classic strength meter counts character classes. Lowercase present, uppercase present, digit present, symbol present: four ticks, R = 94, multiply by length, print a reassuring bar. Feed it P@ssw0rd123! and it computes 12 x 6.5546 = 78.66 bits and calls the password excellent. Feed it the twelve genuinely random characters your password manager just produced and it computes exactly the same 78.66 bits. The meter cannot distinguish them, because it only ever looked at which classes appeared.

An attacker never behaves that way. Real cracking runs a wordlist through a rule file: rules that capitalise, that swap a for @ and o for 0 and s for $, that append two-digit years and four-digit years and a trailing exclamation mark, that reverse and duplicate and truncate. Every transformation in P@ssw0rd123! is a standard rule. Take a ten-million-entry wordlist and ten thousand rules, and the candidate space is 10^11 — about 36.5 bits, exhausted in one second at a hundred billion guesses per second. Against the meter's 78.66 bits that is an overstatement of 42.11 bits, a factor of 4.76 trillion.

Better meters exist and they work on a different principle. Instead of counting classes they try to reconstruct how the password was likely built, matching it against dictionaries, common names, dates, keyboard walks and repeats, then estimating how many guesses the cheapest such reconstruction would take. That is a far more honest number, and it can still only see the patterns it was taught. The safe conclusion is that a meter is a filter against the obviously terrible, not a measurement. If you want a number you can rely on, generate the password and count the bits the generator actually spent.

Longer is not the same as stronger

Two computed examples make the point sharply. Sixteen random lowercase letters give 16 x 4.7004 = 75.21 bits. Twelve random printable ASCII characters give 12 x 6.5546 = 78.66. The sixteen-character string is a third longer and 3.45 bits weaker — about eleven times easier to guess. Length and alphabet trade against each other, and only their product matters.

The gap widens with passphrases. A four-word Diceware passphrase can easily run past twenty characters and still carries only 51.70 bits, against the twelve-character random password's 78.66. That is 26.96 bits less, a factor of 130 million. Passphrases are not weak — they are wonderfully memorable and a six-word one reaches 77.55 bits, effectively matching the twelve random characters. But the strength comes from the number of words drawn, not from the number of letters typed, and four words is not enough for anything you care about.

Time to crack is the defender's number, not yours

Converting entropy into a duration takes one more input: the rate at which the attacker can test candidates. On average they find the password after half the keyspace, so the expected time is 2^(H-1) divided by the guess rate. Everything hangs on that rate, and you as the user do not control it. The service that stores your password does.

Take the four-word Diceware passphrase, 51.70 bits, and vary only the defender's storage choice. Against an unsalted fast hash where a GPU rig manages 10^11 guesses per second, the expected time is 5.1 hours. Against bcrypt at cost 12, where the same rig manages perhaps 10^4 per second, it is 5,790 years. Against Argon2id tuned to 64 MiB of memory, where the memory requirement blocks massive parallelism and the rate falls to around 10^3, it is 57,900 years. Identical password. Identical entropy. Seven orders of magnitude of difference, decided entirely by somebody else.

That is the link between this article and any discussion of hash functions. MD5 and SHA-256 were designed for throughput and deliver it — over a gigabyte per second on a single core — which makes them exactly wrong for password storage. Argon2id, bcrypt and scrypt spend real time and real memory per guess on purpose. When you read a headline claiming a password can be cracked in some number of hours, the first question is which hash the claim assumed, because that single assumption moves the answer by a factor of ten million.

Reuse beats entropy every time

None of this arithmetic matters if the password was already published. Credential stuffing does not guess at all: it takes username and password pairs from one breach and replays them against every other service, and it works because reuse is common. A 78.66-bit password reused across two sites has 78.66 bits at the site that stores it properly and zero at the site that lost it in plaintext, and after that it has zero everywhere. The entropy was never the failure.

Which is why the current guidance from NIST reads the way it does. SP 800-63B dropped the old composition rules — the mandatory uppercase, the mandatory symbol, the forced ninety-day rotation — because they push people toward predictable patterns without buying real entropy. What it recommends instead is a generous minimum length, no arbitrary maximum, no truncation, and screening candidate passwords against lists of known-breached values. That last item is the one that catches P@ssw0rd123!, and no entropy calculation would have.

What to actually do

Generate, do not invent. A password manager drawing from a cryptographic random source is the only way to know your entropy rather than hope for it, and it removes the reuse problem at the same time. For the handful of secrets you must type from memory — the manager's own master password, a disk encryption passphrase, a device unlock — use a six-word Diceware passphrase at 77.55 bits, which you can memorise and which no wordlist attack reaches. Aim for at least 75 bits on anything that guards other credentials, and treat 50 bits as the floor for a routine account behind rate limiting and a second factor.

And build the other side properly, because as a developer you are the defender whose choice decides the numbers in the table above. Store passwords with Argon2id where you can, bcrypt or scrypt where you cannot, always with a unique salt. Do not impose a maximum length or truncate silently. Do not force periodic rotation. Screen new passwords against a breached-password list. Add a second factor, which is worth more bits than any password policy will ever extract from your users.

Frequently asked questions

How many bits of entropy does a password need?

It depends on how the far end stores it, which is the uncomfortable part of the answer. Take 51.70 bits, the entropy of a four-word Diceware passphrase. Against an unsalted fast hash at 10^11 guesses per second, the expected time to find it is 5.1 hours — useless. Against bcrypt at cost 12, roughly 10^4 guesses per second, the same password holds for 5,790 years. So no single threshold is right everywhere. Practical targets: at least 75 bits for anything that protects other credentials, such as a password manager's master secret or a disk encryption passphrase, since those must survive an offline attack on a copy of the data. Around 50 bits is defensible for a routine account behind server-side rate limiting and a second factor, where an attacker never gets to guess quickly. In generated terms, 75 bits means twelve random printable ASCII characters (78.66) or six Diceware words (77.55); 50 bits is four Diceware words (51.70) or eight random characters (52.44).

Is a passphrase stronger than a random password?

Not automatically, and the character count is a poor guide. A four-word Diceware passphrase carries 4 x log2(7,776) = 51.70 bits even though it may run past twenty characters. Twelve random printable ASCII characters carry 12 x log2(94) = 78.66 bits in far less space. The passphrase is 26.96 bits weaker, which is a factor of 130 million in guessing effort — a longer string that is dramatically easier to find. Add words and the picture changes: six words give 77.55 bits, effectively matching the twelve random characters, and seven give 90.47. The real advantage of a passphrase is that you can hold it in your head, which matters enormously for the two or three secrets you must type from memory and not at all for the hundred your password manager fills in. Two conditions apply: the words must be drawn at random from a published list, not chosen by you, and the list size must be known so R is real. Picking four words you like is not Diceware and has no defined entropy.

Why does my password manager rate a password differently from the website?

Because they are answering different questions. A website meter typically counts character classes and multiplies by length, which gives P@ssw0rd123! and twelve genuinely random characters the same 78.66 bits — it cannot tell them apart, having only looked at which classes appeared. A pattern-matching estimator instead tries to reconstruct how the password was probably built, checking it against dictionaries, names, dates, keyboard walks and repeats, and reports how many guesses the cheapest reconstruction would need. On P@ssw0rd123! that is far lower, because every transformation in it is a standard cracking rule: a ten-million-word list crossed with ten thousand rules is 10^11 candidates, about 36.5 bits. The gap between the two verdicts is 42.11 bits, a factor of 4.76 trillion. Trust the pessimistic one. And note that neither can rate a password you generated randomly any better than the formula does, because for a generated password the formula is exact — that is the whole reason to generate rather than invent.

Does adding a symbol and a number really help?

It helps when the character was chosen at random and does nothing when it was chosen the way everyone chooses it. Enlarging the alphabet does raise the per-character yield: log2(26) = 4.7004 bits for lowercase against log2(94) = 6.5546 for the full printable ASCII set, so each random character earns 1.85 bits more. But a capital on the first letter and an exclamation mark at the end are what almost everybody does, so an attacker's rule set produces those variants for free and the real entropy gain is close to zero. That is why NIST SP 800-63B abandoned mandatory composition rules: they impose a predictable transformation rather than adding randomness. If you want more bits, either lengthen the password or genuinely widen the alphabet at random — sixteen random lowercase letters already reach 75.21 bits with no symbols at all, and twelve random characters from all 94 reach 78.66. Both beat any amount of decorating a memorable word.

How is password entropy different from Shannon entropy?

They measure different objects, and a general entropy calculator will happily give you the wrong one. Shannon entropy of a string measures the distribution of symbols within that string: for P@ssw0rd123! it comes to 3.4183 bits per character, driven entirely by which characters repeat. It is the right tool for estimating how well data will compress, or for spotting a block of ciphertext among plaintext, and it tells you nothing about guessability. Password entropy measures the generating process — how many equally likely passwords the procedure could have produced — and that is H = L x log2(R) when the selection really was uniform and random. The two can diverge wildly: a random 12-character password and P@ssw0rd123! have the same H by the formula, 78.66 bits, while their Shannon entropies differ and their actual resistance to guessing differs by tens of bits. If you are choosing a password, the generating process is the number that matters.

Can I just make my password longer instead of random?

Length only converts into entropy when the added characters were unpredictable. Extending a memorable word with a birth year and a punctuation mark lengthens L on paper while an attacker's rule file generates exactly those endings for free, so H = L x log2(R) no longer describes anything real — the practical search space stays around the size of the wordlist times the rule set, roughly 10^11 candidates or 36.5 bits, which is one second of work at a hundred billion guesses per second. Length applied to genuinely random material is the most efficient lever you have: each extra random lowercase letter adds log2(26) = 4.7004 bits and each extra random printable ASCII character adds log2(94) = 6.5546. Sixteen random lowercase letters reach 75.21 bits — no symbols, no capitals, no substitutions, and far stronger than any decorated dictionary word. So yes, go long, but only if the added length is random. If you need to remember it, add Diceware words rather than characters: each one is worth 12.9248 bits.