How Long Should a Password Be? Entropy Explained
For a randomly generated password, aim for at least 60 bits of entropy for ordinary accounts, 80 bits for sensitive ones, and 128 bits when you want margin for decades. Entropy is governed by the formula H = L × log2(R), where length L dominates the alphabet size R. In practice that means roughly 13 characters from a 94-symbol set, or about 20 lowercase letters.
The entropy formula: H = L x log2(R)
Password strength against brute force is measured in bits of entropy. The formula is H = L × log2(R), where L is the password length in characters and R is the size of the character pool each position is drawn from. The result, H, is the base-2 logarithm of the total number of possible passwords, so every extra bit doubles the search space an attacker must traverse.
The character pool sizes you will encounter most often are: 26 for lowercase only, 52 for mixed case, 62 once you add digits, and roughly 94 for the full set of printable ASCII including symbols. Each character therefore contributes log2(R) bits: about 4.70 bits for lowercase, 5.70 for mixed case, 5.95 for mixed-case alphanumeric, and 6.55 for the full ASCII set.
You can compute it directly. The Python below prints the entropy of any length-and-pool combination, which is all the math a generator needs under the hood.
import math
def entropy(length, pool):
return length * math.log2(pool)
print(entropy(8, 94)) # 52.44 bits (8 chars, full ASCII)
print(entropy(13, 94)) # 85.21 bits
print(entropy(20, 26)) # 94.02 bits (20 lowercase)
The 60 / 80 / 128-bit targets
Three thresholds cover almost every real decision. Around 60 bits is the practical floor for an account that sits behind a slow hash and rate limiting; below that, an offline attacker with modern hardware closes the gap uncomfortably fast. Around 80 bits is the figure commonly recommended for privileged accounts, admin credentials, and anything whose compromise cascades. 128 bits is the symmetric-crypto comfort zone: it is computationally infeasible to brute force regardless of hardware advances on any timeline worth planning for.
| Entropy target | Use case | Full-ASCII length | Lowercase length |
|---|---|---|---|
| 60 bits | Ordinary accounts | ~10 chars | ~13 chars |
| 80 bits | Privileged / sensitive | ~13 chars | ~18 chars |
| 128 bits | Long-horizon secrets, keys | ~20 chars | ~28 chars |
These lengths assume each character is chosen uniformly at random. That assumption is the whole game, and it is also the catch we return to below.
Why length beats complexity
In H = L × log2(R), length L is a linear multiplier while the alphabet R only enters through a logarithm. Growing the pool gives diminishing returns; growing the length does not. This is why a long simple password beats a short complex one, and the numbers are stark.
An 8-character password using every printable ASCII symbol gives 8 × 6.55 = 52.4 bits. A 20-character password using nothing but lowercase letters gives 20 × 4.70 = 94.0 bits, more than 40 extra bits, meaning roughly a trillion times larger search space, despite using a quarter of the character variety. The mixed-case-digit-symbol password your corporate policy demands is mathematically weaker than a longer, simpler string.
This is also the reasoning behind NIST SP 800-63B, which dropped mandatory composition rules (forced uppercase, digits, symbols) and now emphasizes length, allowing minimums of 8 and recommending 15 or more. Forced complexity pushes humans toward predictable patterns like P@ssw0rd1 that gain almost no real entropy. If you generate randomly, optimize for length first. A tool like the password generator lets you crank length up while keeping every character independent and uniform.
The dictionary-attack caveat: entropy isn't everything
The formula only holds when every character is drawn independently and uniformly at random. The moment a human chooses the password, that assumption collapses. People pick words, names, dates, keyboard walks, and leetspeak substitutions, so the effective entropy is far below the theoretical figure. Tr0ub4dor&3 looks like 11 characters of full-ASCII entropy (about 72 bits) but is really a dictionary word plus predictable mangling, which a rules-based attack like hashcat tests in seconds.
Attackers do not brute force the full keyspace blindly. They run wordlists such as rockyou.txt, apply transformation rules, and exploit the non-uniform distribution of human choices. This is why NIST moved away from entropy estimates toward guessability-based metrics and why it now mandates blocklisting known-breached passwords. The takeaway is not that entropy is useless, but that the formula only describes randomly generated secrets. For a passphrase, use enough independent words: five or six random words from a large list reaches the 60-to-80-bit range, while a memorable-looking sentence you invented yourself does not.
Crack time depends on the hash, not just entropy
Two passwords with identical entropy can have wildly different real-world crack times, because the cost of testing one guess depends entirely on how the password was stored. Entropy sets the number of guesses; the hash function sets the price per guess.
Fast general-purpose hashes are a disaster for password storage precisely because they are fast. A single high-end GPU computes on the order of 100 to 200 billion MD5 hashes per second and roughly 2 to 22 billion SHA-256 hashes per second, so the entire rockyou.txt list falls in well under a second. Purpose-built password hashes are deliberately slow and, for Argon2id, memory-hard: bcrypt at cost 12 drops a GPU to only a few hundred guesses per second, and Argon2id's memory requirement erases most of the GPU's parallelism advantage, leaving it barely faster than a CPU.
| Algorithm | GPU throughput (order of magnitude) | Use for passwords? |
|---|---|---|
| MD5 | ~100-200 billion/s | Never |
| SHA-256 | ~2-22 billion/s | Never |
| bcrypt (cost 12) | ~hundreds/s | Acceptable |
| Argon2id (memory-hard) | ~ones/s, GPU-resistant | Recommended |
The OWASP Password Storage Cheat Sheet recommends Argon2id with m=19456 (19 MiB), t=2, p=1, or the equivalent m=47104 (46 MiB), t=1, p=1, with bcrypt at work factor 10 or higher as the fallback. If you are inspecting a stored hash to identify its algorithm, the hash generator shows what common algorithms produce, and you can verify a token's claims with the JWT decoder. The practical rule: pick length for entropy, and pick the slowest acceptable hash for storage, because a high-entropy password behind MD5 is far weaker than a modest one behind Argon2id.
Frequently Asked Questions
For randomly generated passwords, 60 bits is a practical minimum for ordinary accounts and 80 bits is recommended for privileged or sensitive accounts. 128 bits gives long-term margin against future hardware and is the comfort zone for keys and long-lived secrets.
Yes, for randomly generated strings. Length is a linear multiplier in H = L x log2(R) while alphabet size only enters through a logarithm. A 20-character random lowercase password has about 94 bits of entropy versus about 52 bits for an 8-character full-ASCII password.
No. H = L x log2(R) assumes every character is chosen independently and uniformly at random. Human-chosen passwords use words, patterns, and predictable substitutions, so their real entropy is far lower and dictionary or rules-based attacks crack them quickly.
Entropy sets the number of guesses an attacker must try, but the hash sets the cost per guess. A GPU computes billions of MD5 or SHA-256 hashes per second, while bcrypt and Argon2id are deliberately slow and memory-hard, dropping throughput to hundreds or single digits per second.