"Entropy" gets used constantly in password advice, usually without a working definition. This article gives the actual calculation, shows why a password that "looks" complex can have less entropy than a longer, simpler-looking one, and explains how to reason about entropy when setting a real password policy.
In short
Entropy measures unpredictability, not appearance — a password only has the entropy the formula promises if it was actually generated by a uniform-random process (e.g., a password generator), not chosen or patterned by a person. Length reliably raises entropy; composition rules mostly don't. Use the Password Strength Checker to see this scored against a real password.
What entropy actually measures
In the context of passwords, entropy is a measure of unpredictability, expressed in bits. It answers a specific question: if an attacker knows the method used to generate a password (the character set, the length, the selection process) but not the specific value chosen, how many guesses would they need, on average, to find it by brute force?
Entropy is not a property of a single password string in isolation — it's a property of the random process that generated it, combined with the length of the result. This is the detail most casual explanations get wrong: two identical-looking passwords can have wildly different real-world entropy depending on how they were chosen.
The calculation
For a password generated by selecting characters uniformly at random from a character set of size N, choosing a password of length L, the entropy in bits is:
entropy (bits) = L × log2(N)
| Character Set | Set Size (N) | Bits per Character | 12-char Entropy | 16-char Entropy |
|---|---|---|---|---|
| Digits only (0–9) | 10 | 3.32 | 39.9 bits | 53.2 bits |
| Lowercase letters (a–z) | 26 | 4.70 | 56.4 bits | 75.2 bits |
| Lowercase + digits | 36 | 5.17 | 62.1 bits | 82.8 bits |
| Upper + lower + digits | 62 | 5.95 | 71.4 bits | 95.2 bits |
| Upper + lower + digits + symbols | 94 | 6.55 | 78.6 bits | 104.8 bits |
For a passphrase built from words drawn randomly from a word list, the calculation is the same idea applied to whole words instead of characters:
entropy (bits) = number of words × log2(word list size)
A four-word passphrase drawn from a 7,776-word list (log2(7776) ≈ 12.9 bits per word) yields roughly 51.5 bits of entropy — comparable to a 9-character fully random string using the full 94-character set, but dramatically easier for a person to remember and type accurately. See Passphrase vs. Password for the full comparison.
Why a "complex-looking" password can have low real-world entropy
The formula above assumes uniform random selection from the full character set — every character equally likely, with no pattern. This assumption breaks immediately for human-chosen passwords, even ones that satisfy composition rules.
Summer2024! looks complex: it has uppercase, lowercase, digits, and a symbol, spanning the full 94-character set. If it were genuinely randomly generated from that set, an 11-character string would carry about 72 bits of entropy. But Summer2024! isn't randomly generated — it's a dictionary word, a predictable year, and a symbol appended at the end, which is one of the most common human patterns for satisfying a composition rule. Password-cracking tools (Hashcat, John the Ripper, and similar) are built around exactly these patterns: dictionary words with common substitutions and appended digits/symbols are tested before anything resembling true brute force. The effective entropy of Summer2024! — the number of guesses a well-built cracking tool actually needs — is far closer to 20–25 bits than 72.
To make "guesses per second" concrete: modern GPU-based cracking rigs can attempt on the order of tens of billions of guesses per second against a fast, unsalted hash (far more for hash algorithms specifically chosen to be fast, far fewer against a deliberately slow algorithm like bcrypt or Argon2 — see the storage note below). Rather than testing all 94^11 possible 11-character combinations in pure brute-force order, these tools run a dictionary-and-mutation attack first: a list of common words and known-breached passwords, each tested with a library of common mutations (append a digit, capitalize the first letter, substitute @ for a). Summer2024! sits directly inside that mutation list's early search space, so it's typically found in seconds to minutes, not the years true 72-bit brute force would take.
Composition rules measure the wrong thing
A composition rule ("must include one number and one symbol") checks whether specific character classes are present, not whether the password is unpredictable. This is exactly why NIST moved away from mandating composition rules in favor of length and breached-password screening — see NIST Password Guidelines.
How much entropy is "enough"
There's no single universal threshold, because required entropy depends on what's defending the account beyond the password itself (rate limiting, lockout policies, MFA) and how fast an attacker could plausibly test guesses (online guessing against a rate-limited login form is vastly slower than offline cracking of a stolen password hash database).
As practical reference points commonly used in security engineering:
- Below ~28 bits: crackable in a practical amount of time even against reasonably defended systems; equivalent to a short, simple word-based password.
- ~40–60 bits: reasonable for accounts protected by rate limiting and lockout policies, and the realistic range for a well-generated passphrase or an 8–10 character fully random password.
- ~70+ bits: strong even against offline attacks on a stolen hash (assuming the hash is stored with a modern algorithm — see below); the realistic range for a 12+ character random password or a 5+ word passphrase, and appropriate for a password manager master password.
Entropy assumes the hash isn't cheaply crackable
Entropy calculations describe the password itself. They don't account for how a compromised system stores it. A password with 80 bits of entropy protected by a fast, unsalted hash can still be cracked faster than expected if the hashing algorithm itself is weak. Entropy and hashing strength are separate, complementary controls — this article covers the former; secure credential storage is a separate, system-design topic.
Practical takeaways for a business policy
- Length is doing almost all of the entropy work in any policy that permits (or requires) full-length random strings — a longer minimum length raises the entropy floor for every account far more reliably than composition rules.
- Composition rules should be treated as a floor, not a strength signal. A password satisfying every composition rule can still have low effective entropy if it's built from a dictionary word and predictable substitutions.
- Breached-password screening compensates for the fact that entropy calculations assume randomness that human-chosen passwords rarely have. It directly filters out the low-effective-entropy passwords that pass composition checks.
- System-generated passwords and passphrases should use the calculation above deliberately — this is exactly what a password generator tool does under the hood, selecting uniformly at random from a defined character set or word list to guarantee the entropy the formula promises, rather than relying on human unpredictability.
Common mistakes
- Assuming a password's entropy from its appearance rather than its generation method. Entropy is a property of the random process that created the password, not something you can eyeball from the final string — a "complex-looking" password can have far lower effective entropy than a longer, plainer-looking randomly generated one.
- Crediting composition rules with entropy they don't add. Requiring a symbol only raises entropy if the symbol's position and identity are also randomly chosen — "always a symbol at the end" is a pattern, not randomness, and cracking tools test that pattern directly.
- Ignoring what's defending the account besides the password. The same password has very different real-world risk behind a rate-limited login form versus in a stolen, poorly-hashed credential database — entropy alone doesn't capture that.
- Treating a strength meter's score as an authoritative entropy measurement. Most meters (including simple ones) use heuristics, not a rigorous calculation — useful as directional feedback, not as a certification.
FAQ
Does adding a symbol always increase entropy?
Only if the symbol is chosen randomly from the available symbol set, in a position that isn't predictable. Appending ! at the end of a word — the most common human pattern — adds far less real entropy than the character-set math would suggest, since cracking tools test that exact pattern first.
Is a 16-character random password always stronger than an 8-character one? For passwords generated by the same uniform-random process from the same character set, yes — entropy scales directly with length. This assumes both are actually randomly generated; a predictable 16-character phrase can still have lower effective entropy than a properly random 8-character string.
How is this different from "password strength meters" in login forms? Most strength meters use heuristics (length, character variety, presence in a small blocklist) rather than a rigorous entropy calculation, and vary widely in accuracy between implementations. They're a reasonable directional signal for end users but shouldn't be treated as an authoritative entropy measurement.
Related reading
- NIST Password Guidelines
- Passphrase vs. Password
- Password Manager Guide
- Password Strength Checker — score a real password against these principles
- Password Generator — generate a password with the entropy this article describes
- Download: Password Security Checklist