Password entropy explained: what actually makes a password strong

Password strength has a unit: bits of entropy, where each bit doubles the number of guesses an attacker must make on average. A password worth 40 bits takes 2^40 guesses to brute-force exhaustively, about a trillion; 80 bits is 2^80, roughly a septillion. Entropy is not a property of a single password — it is a property of the process that produced it. That distinction is where most intuition about strong passwords goes wrong, and it's worth getting precise about before trusting any number.

The formula, and what it assumes

For a password drawn uniformly at random from a pool of N distinct symbols, with length L, the entropy in bits is:

H = L × log2(N)

The pool size N is how many characters each position could equally have been. A 12-character password chosen at random from the 95 printable ASCII characters carries:

12 × log2(95) = 12 × 6.5699 ≈ 78.8 bits

That value is exact only under one condition: every position was filled by an independent, uniform random draw. The moment a human chooses the characters — or a rule constrains them — the real entropy drops, often by more than half, and the formula stops describing the password an attacker actually faces.

Bits per character by pool

Each position contributes log2(N) bits. The common pools:

Character pool	Size N	Bits per character
Digits 0-9	10	3.32
Lowercase a-z	26	4.70
Lowercase + digits	36	5.17
Alphanumeric a-zA-Z0-9	62	5.95
Full printable ASCII	95	6.57

Divide the entropy target by bits-per-character to get the length you need from a random generator:

Target	Digits	Lowercase	Alphanumeric	Full ASCII
~80 bits	25 chars	18 chars	14 chars	13 chars
~128 bits	39 chars	28 chars	22 chars	20 chars

The table shows why "add a symbol" buys less than people expect. Going from alphanumeric to full ASCII adds only 0.62 bits per character — about 7.5 extra bits across a 12-character password. Adding two more random characters to the same pool adds 11.9. Length is the cheaper lever, and it compounds linearly with no upper bound on the pool's diminishing returns.

Why human-chosen passwords are weaker than the math says

P@ssw0rd! has nine characters from the full ASCII pool. The formula says 59 bits. Its real entropy against a competent attacker is closer to a dozen, because no attacker enumerates 95^9 candidates blindly. They model how humans choose:

• Dictionaries and breach corpora. The word password and its millions of seen variants are tried first. Lists like rockyou.txt and the HaveIBeenPwned corpus turn billions of real passwords into a ranked guessing order.
• Leetspeak substitution. a→@, o→0, s→$, i→1 are a tiny, well-known transformation set. Tools like hashcat apply them as rules over a base wordlist at almost no extra cost.
• Keyboard walks. qwerty, 1qaz2wsx, asdfgh are short paths across the keyboard, a few thousand candidates total.
• Predictable placement. Capital first, digits and a symbol at the end. Composition rules concentrate humans into this pattern, which shrinks the search space rather than expanding it.

The lesson is blunt: a random 13-character full-ASCII string (~85 bits) is dramatically stronger than a human-crafted 16-character password that satisfies every complexity checkbox but follows a predictable shape. Entropy lives in the generator, not the keyboard. This also explains why entropy matters even when an attacker never touches your live login — if a password database leaks, cracking is done offline at billions of guesses per second against the stored hashes, and only the entropy of the original password limits how far they get (see hashing vs encryption vs encoding).

Passphrases: entropy you can remember

Diceware sidesteps the human-pattern problem by making the words random. You roll dice to pick words from a fixed list, and the entropy is:

H = words × log2(wordlist size)

The standard EFF/Diceware list has 7776 words (6^5, one entry per five-die roll), so each word contributes log2(7776) ≈ 12.92 bits. A six-word passphrase:

6 × 12.92 ≈ 77.5 bits

That clears the ~80-bit neighborhood, is memorable as a phrase like anvil-collide-runway-fossil-mocha-stout, and — critically — the entropy holds even when the attacker knows you used Diceware and has the exact wordlist. Knowing the method doesn't help; the randomness is in the dice. Bump to seven words for ~90 bits, eight for ~103. The separators and capitalization add nothing meaningful and shouldn't be counted toward the strength claim.

Modern guidance: length and screening, not theater

NIST SP 800-63B (Rev. 4) reorganized password policy around what actually resists attack, and the shift is worth internalizing because much deployed policy still contradicts it:

• Favor length. Require at least 8 characters, support at least 64, and treat length as the primary strength lever. When a password is the only authenticator, the recommended floor rises to 15.
• Screen against blocklists. Reject passwords found in breach corpora, dictionaries, repetitive or sequential strings, and context-specific terms (the service name, the username). This is where real-world strength is enforced.
• Drop mandatory composition rules. NIST now says verifiers shall not require specific character-type mixes. Those rules push users toward the predictable patterns above and lower effective entropy.
• Drop periodic forced rotation. Don't expire passwords on a schedule. Rotate only on evidence of compromise. Forced rotation drives incremental, guessable changes (Spring2025! → Summer2025!).

The throughline: stop optimizing for a formula that assumes randomness the user never had, and instead block the guesses attackers actually make. A second factor like TOTP does far more for account security than any composition rule, because it removes the password from being a single point of failure entirely.

Where to set the bar

Entropy targets should track what the secret protects and how long it lives:

• Low-value, rate-limited, throwaway accounts: ~40–50 bits is defensible if online guessing is throttled and lockouts apply. An attacker who can only try a few per second won't exhaust 2^45.
• Anything with a recoverable or offline-crackable hash: aim for ~80 bits or more. Once the hash leaks, rate limits vanish and the attack runs at hardware speed.
• Cryptographic keys, API tokens, session secrets: 128 bits, full stop. These are machine-generated, never typed, and protect things that justify the strongest realistic margin. A 22-character random alphanumeric or 20-character full-ASCII string clears it.

Two honest limits. First, "bits of entropy" describes resistance to brute force, not to phishing, credential stuffing of reused passwords, keyloggers, or a leaked plaintext — a 128-bit password reused across sites is still one breach away from worthless. Second, the entropy of a human-chosen password can't be measured by any formula; strength meters that score P@ssw0rd! highly are estimating pattern resistance poorly, and you should treat their numbers as motivational, not precise.

The reliable path is to remove human pattern from the equation entirely: generate the secret randomly at the length your threat model demands. Our password generator draws from the pool you choose using a cryptographically secure source, so the L × log2(N) figure it reports is the entropy you actually get — not an optimistic estimate of a string your fingers would have typed.