Password Entropy Explained: Bits, Math and Real Crack Times

When a strength meter calls a password "strong," it's making a guess about one number: entropy. Entropy is the only honest measure of password strength because it counts the thing attackers actually care about - How many candidates they must try before finding yours. The concept takes ten minutes to understand, and once you do, most password folklore evaporates. You can compute for yourself why Tr0ub4dor&3 is weak, why four random words are strong, and why the same password can be safe on one website and doomed on another.

What a "bit" of entropy means

Entropy, measured in bits, is the base-2 logarithm of the number of equally likely possibilities your password was drawn from. One bit means two possibilities - A coin flip. Ten bits means 2¹⁰ = 1,024 possibilities. Forty bits is about a trillion.

The definition has a crucial condition: the possibilities must be equally likely, which means the password must be chosen at random. Entropy is a property of the process that produced the password, not of the string itself. Jk8$fq2Lp! has ~66 bits if a generator produced it - And close to zero if it's printed in this article and you copy it.

The power of bits is that each one doubles the attacker's work:

The formula: pool size and length

For a password of length L drawn uniformly from a pool of N characters:

Entropy = L × log₂(N)

Each character class contributes a fixed number of bits per character:

Two lessons hide in that table. First, length beats pool size: going from letters-plus-digits to full symbols adds ~0.6 bits per character, while adding one more character adds ~6. Second, words are just characters from a huge alphabet - One word from the EFF's 7,776-word Diceware list is worth 12.9 bits, so a six-word phrase from a passphrase generator reaches ~77.5 bits while staying memorable. That trade-off is the entire argument for word-based passwords.

The same math explains why PINs are only ever a local defense: a 4-digit PIN has 13.3 bits - 10,000 possibilities - Which is fine when a phone wipes itself after ten failures and hopeless anywhere an attacker gets unlimited tries. If you need one, at least make it random with a PIN generator rather than using a birthday.

Why human passwords lie about their entropy

Apply the formula naively to Sunshine2026! and you get 13 characters × 6.57 bits ≈ 85 bits. The real figure is closer to 25–30 bits. The formula assumes every character was an independent random draw; in reality the password is one dictionary word (~16 bits for a common-word choice), a plausible year (~7 bits), and the single most common symbol in the single most common position (~2 bits). Attackers don't search the 95-character space - They search the human space of words, dates, and predictable decoration first, using rule engines trained on billions of leaked passwords. NIST SP 800-63B makes this point bluntly: composition rules do little because users satisfy them in predictable ways.

Entropy is measured against the smartest attack, not the dumbest. If a pattern exists, assume the cracking rig knows it.

This is also why estimator tools disagree with each other. Good ones (like zxcvbn-style estimators) model dictionaries and patterns; naive ones just apply the formula and flatter you.

From bits to seconds: the attacker's speed

Crack time = 2^bits ÷ guesses-per-second (on average, half that, since the attacker expects to find you halfway through the space). The guesses-per-second term varies by a factor of a billion depending on the scenario:

• Online guessing against a live login page: tens to hundreds of guesses per second before rate limits and lockouts bite. Even 30 bits survives a while here.
• Offline cracking of a fast hash (MD5, SHA-1, or unsalted SHA-256): a single modern GPU tests tens of billions of MD5 candidates per second; a rig of them, hundreds of billions. This is the scenario behind Hive Systems' famous crack-time tables, where short passwords fall instantly.
• Offline cracking of a slow hash (bcrypt, scrypt, Argon2): deliberately expensive functions cut the rate to thousands or tens of thousands of guesses per second per GPU - A millionfold penalty for the attacker.

So the same 45-bit password could hold for centuries against an online attack, fall in minutes to an MD5 rig, and hold for years under bcrypt. You control the entropy; the website controls the hashing. Since you rarely know which hash a site uses - See MD5 vs SHA-256 vs bcrypt for why it matters so much - The rational move is to assume the worst and carry enough bits that even the fast-hash scenario is hopeless. The mechanics of these attacks, from dictionaries to rainbow tables, are covered in how hackers crack passwords.

Worked examples

• 123456 - Not a random draw from anything; it's the #1 entry in every cracking wordlist. Effective entropy ≈ 0 bits. Found on guess one.
• 8 random lowercase letters (qmzwvbjk) - 8 × 4.7 = 37.6 bits ≈ 209 billion possibilities. An MD5 rig doing 100 billion guesses/second exhausts it in ~2 seconds.
• 12 random mixed-case + digits (aK92mQx7Lp3v) - ~71 bits ≈ 2.4 × 10²¹. Same rig: ~750 years on average. Under bcrypt: geological time.
• 6 Diceware words - 77.5 bits ≈ 2 × 10²³. Safe in every realistic scenario, and you can actually remember it.

Note what happened between examples two and three: four extra characters and a slightly larger pool turned seconds into centuries. Entropy is exponential; small increases in length dominate everything else. This is the core reason how to create a strong password boils down to "make it longer and make it random."

What entropy can't tell you

Entropy predicts resistance to guessing. It says nothing about phishing, keyloggers, or a site storing passwords in plaintext - A 128-bit password typed into a fake login page is captured as easily as password1. It also can't rescue a reused password: once your exact string is in a breach corpus, its entropy is irrelevant because it's now literally on the attacker's list. Strength and uniqueness are separate properties; you need both, and the generators that provide them are only trustworthy if their randomness is real - Which is what how random password generators actually work digs into.

FAQ

How many bits of entropy should a password have?

Around 80 bits is a sound target for regular accounts, comfortably beyond offline GPU attacks even against fast hashes. For master passwords, disk encryption, or anything that must resist a determined offline attacker for decades, aim for 90–100+ bits - A random 16-character password or a seven-word Diceware passphrase.

Does adding a symbol really help?

Marginally. Moving from letters-and-digits (5.95 bits/char) to all printable ASCII (6.57 bits/char) adds about 0.6 bits per character, while each additional character of any kind adds roughly 6. One extra random character beats sprinkling symbols through a shorter password - Though if a random generator gives you symbols for free, take them.

Why do strength checkers give different scores for the same password?

Because entropy depends on the assumed attack model. Naive checkers multiply length by bits-per-character and overrate human patterns; smarter estimators model dictionary words, keyboard walks, dates, and leet substitutions the way real cracking tools do, and score them far lower. Trust the pessimistic estimate.

Is a long sentence I made up as strong as a Diceware passphrase?

Usually not. Song lyrics, quotes, and grammatical sentences are drawn from a much smaller effective space than random words - Cracking tools include phrase dictionaries and combinator attacks. Five words chosen by real dice or a cryptographic generator carry a provable ~65 bits; a sentence you thought of has unknowable, usually much lower, entropy.

Can entropy be measured from the password string itself?

Not truly. Entropy belongs to the generation process, so a tool can only estimate by modeling how the string might plausibly have been produced. That's why Jk8$fq2Lp! from a generator is strong, but the identical string, once published in an article, is worth zero bits.