Password Strength Is Mostly Length: Entropy, Crack Times, and What Actually Helps
Most advice about passwords is folklore. "Use a mix of upper and lower case, numbers, and symbols" has been drilled into people for two decades, and it is mostly wrong — or at least, it optimizes the wrong variable. If you understand one idea, the rest of password security falls out of it almost mechanically. That idea is entropy, and the punchline is that it is dominated by length, not by how clever your character substitutions look. This is the model I keep in my head, and it is the same math a strength checker is running under the hood.
What entropy actually measures
Password entropy is a measure of how many guesses an attacker needs, on average, to land on your password — expressed in bits. For a password drawn randomly from a character set, the formula is simple:
bits = length × log2(size of character set)
The character set is the pool of symbols each position could have been. Lowercase letters give you 26 possibilities, so each character contributes log2(26) ≈ 4.7 bits. Add uppercase and you are at 52 (≈ 5.7 bits per char). Add digits: 62 (≈ 5.95 bits). Throw in a typical set of symbols and you reach roughly 95 printable ASCII characters (≈ 6.57 bits per char).
The crucial property of bits is that they are a log scale. Each additional bit doubles the number of guesses an attacker must make. Eight bits is 256 possibilities; nine bits is 512; ten is 1,024. So when you compare two passwords, you are not comparing their lengths or their "complexity" directly — you are comparing two exponents.
Why a longer lowercase password beats a short mixed one
This is where the folklore breaks. Compare two passwords, assuming both are genuinely random:
An 8-character password using the full 95-symbol set: 8 × 6.57 ≈ 52.5 bits.
A 12-character password using only lowercase letters: 12 × 4.7 ≈ 56.4 bits.
The all-lowercase password is stronger, despite having none of the "complexity" the old rules demand. Length entered the formula as a multiplier, while the larger character set only nudged the per-character contribution. Four extra characters of plain lowercase bought more entropy than every symbol on the keyboard did. That is the single most useful thing to internalize: adding length scales entropy faster than enriching the alphabet.
Crack times, and the attacker you are assuming
A strength meter that tells you "it would take 3 million years to crack this" is making a long chain of assumptions, and the number is only as honest as those assumptions. Crack time is just entropy divided by guess rate, and the guess rate depends entirely on the kind of attack.
Online, throttled attacks
If an attacker is guessing against a live login form, they are limited by the server: rate limits, lockouts, network latency. They might manage a few guesses per second at best before getting blocked. Against this attacker, even a fairly modest password holds up for an absurdly long time, because the bottleneck is the server, not the math.
Offline attacks against a fast hash
The dangerous scenario is when a database leaks and the attacker has the password hashes in hand. Now there is no rate limit — they guess as fast as their hardware allows. If the site stored passwords with a fast, general-purpose hash like a bare SHA-256 (which is the wrong choice for passwords; see how hashing works), commodity GPUs can compute billions of candidate hashes per second. Against that throughput, a 40-bit password is gone in seconds.
Offline attacks against a slow hash
This is why password-specific hashing functions exist. bcrypt, scrypt, and argon2 are deliberately slow and memory-hard. They take a tunable cost parameter so that a single hash takes a meaningful fraction of a second instead of nanoseconds. That collapses the attacker's guess rate from billions per second to thousands per second, which adds the equivalent of roughly 20+ bits of margin without the user changing their password at all.
The takeaway: a crack-time estimate is an estimate, not a guarantee. It bakes in a guess about the attacker's hardware and the defender's hashing choice — neither of which you control as the person typing the password. Treat the meter's "centuries" as "this password is not the weak link," not as a literal promise.
Why length beats complexity — and why "P@ssw0rd" fools nobody
The complexity rules fail for a second, sharper reason: real attackers do not guess randomly. They guess smart. Cracking tools like the ones built on large leaked-password corpora start with dictionary words, common patterns, and then apply transformation rules — capitalize the first letter, append a year, swap a for @, o for 0, s for $.
Those exact substitutions are the first things tried, not the last. "P@ssw0rd" is not a 95-symbol-alphabet password in any meaningful sense; it is the dictionary word "password" plus a rule the cracker already knows. Its real-world entropy is close to that of the bare word — near zero. The entropy formula assumes randomness; the moment your password is a predictable transformation of something a human would think of, the formula overstates its strength badly.
This is the gap between theoretical entropy (what the formula computes assuming randomness) and practical entropy (how a smart attacker actually searches). Length helps both. Predictability destroys the second one regardless of how the first one looks.
The thing a strength meter can never tell you
Here is the limit you have to respect: a strength meter scores a password in isolation. It has no idea whether that password has already appeared in a breach. A password that looks flawless — long, random, high-entropy — is worthless if you reused it on a site that got breached and dumped. The attacker is not cracking it; they already have it in plaintext from somewhere else and they are simply trying it everywhere (this is credential stuffing).
So strength and safety are two different questions. Strength asks "how hard is this to guess?" Safety asks "is this already in someone's wordlist?" The only fix for the second question is structural: a unique password per site, plus a habit of checking your important credentials against a breach-notification service so you know when to rotate.
What actually helps, concretely
Strip away the folklore and the genuinely useful practices are short:
Use a password manager
This is the single highest-impact change. Let it generate 16+ truly random characters per site and store them. You never type them, never reuse them, and never have to remember them. Sixteen random characters from a full alphabet is north of 100 bits — comfortably past any offline-cracking concern, and unique everywhere so a breach on one site never touches another.
Use passphrases for the few you must type
You cannot delegate everything to a manager — your device login and the manager's own master password have to live in your head. For those, use a passphrase: four or five randomly chosen words. "correct-battery-staple-thirsty" style. Random word choice from a large list yields plenty of entropy and is far easier to type and remember than a random character soup. The word "randomly" is load-bearing — pick them with a generator or dice, not from a sentence you made up. The password generator has a dedicated passphrase mode for exactly this — choose how many random words, the separator, and whether to add a number or symbol — alongside a random-character mode and Easier / Strong / Max presets. It runs entirely in your browser, so nothing it produces is ever transmitted.
Turn on 2FA, and stop reusing passwords
Two-factor authentication means a stolen or cracked password alone is not enough to get in. Prefer an authenticator app or a hardware key over SMS where you can. And the cardinal rule, worth repeating: never reuse a password across sites. Reuse is what turns one site's breach into a compromise of your whole online life.
That is the whole model. Entropy is length times the log of the alphabet, length is the lever that matters, crack-time numbers are estimates that hinge on the attacker you assume, and no meter can see a breach. Get a password manager doing the work, keep a couple of strong passphrases in your head, switch on 2FA, and stop reusing — and you have done more for your security than any amount of @-for-a swapping ever could. If you want to see the entropy math react to your own input, the strength checker runs it live, entirely in your browser. And if you are wiring up authentication yourself, the same care applies to the tokens you hand out — the guide on decoding JWTs safely covers the next layer down.