How Strong Is Your Password, Really? The Entropy Math Behind Crack Times
"Use upper case, lower case, a number, and a symbol" is the advice everyone's heard. It's not wrong, but it's incomplete — length matters more than most people assume, sometimes more than complexity does. Here's the actual math, run through the site's Password Entropy Calculator, across enough scenarios to see the pattern clearly.
The formula, briefly
A password drawn from a character set of size C has CL possible combinations for length L. An attacker guessing at rate G per second finds it, on average, after trying half the space: crack time ≈ (CL ÷ 2) ÷ G. The character-set sizes: lowercase 26, uppercase 26, digits 10, symbols 32 — so "all four" gives a pool of 94 characters per position, versus 26 for lowercase-only.
Worked examples, at a fast offline GPU attack (10 billion guesses/second)
| Password | Character pool | Entropy | Time to crack |
|---|---|---|---|
| 4 chars, lowercase only | 26 | 18.8 bits | less than a second |
| 6 chars, all 4 types | 94 | 39.3 bits | 34.5 seconds |
| 8 chars, lowercase only | 26 | 37.6 bits | 10.4 seconds |
| 8 chars, all 4 types | 94 | 52.4 bits | 3.5 days |
| 10 chars, all 4 types | 94 | 65.5 bits | 85.4 years |
| 12 chars, lowercase only | 26 | 56.4 bits | 55.2 days |
| 12 chars, all 4 types | 94 | 78.7 bits | ~755,000 years |
| 14 chars, all 4 types | 94 | 91.8 bits | ~6.7 billion years |
| 16 chars, all 4 types | 94 | 104.9 bits | ~59 trillion years |
The line worth staring at: 12 plain lowercase letters (55.2 days) beats 8 characters using every character type (3.5 days) — four extra characters of length outweighs adding uppercase, digits, and symbols to a shorter password. This is why "use a long passphrase" (four or five random words) is genuinely solid advice: length is cheap to add and compounds fast, because each extra character multiplies the total space rather than adding to it.
The strength label, and where the thresholds actually sit
The calculator's strength label follows entropy directly, not vibes:
| Entropy | Label | Example |
|---|---|---|
| Under 28 bits | Very weak | 4-character lowercase PIN-like string |
| 28–36 bits | Weak | 6-character lowercase-only password |
| 36–60 bits | Fair | 8-character mixed, or 10-character lowercase-only |
| 60–128 bits | Strong | 10-character mixed, 12-character lowercase-only |
| 128+ bits | Very strong | 16+ character mixed, or a long passphrase |
What attacker speed does to the same password
Crack time isn't a fixed property of a password — it scales directly with how fast the attacker can guess. A 10-character mixed password (94-character pool) looks very different depending on what it's up against:
| Attacker scenario | Guess rate | Time to crack a 10-char mixed password |
|---|---|---|
| Online, rate-limited (a login form that throttles attempts) | 1,000/sec | 854 million years |
| Offline, slow hash (a well-hashed but leaked database) | 1 million/sec | 854 thousand years |
| Offline, fast GPU (a poorly-hashed leaked database) | 10 billion/sec | 85.4 years |
| Offline, dedicated cracking farm | 1 trillion/sec | 311.7 days |
This is exactly why how a service stores your password matters as much as the password itself — a properly slow, salted hash (like bcrypt or Argon2) keeps even a leaked database in the "million/sec" tier rather than the "billion/sec" tier, turning an 85-year password into an 854,000-year one. You can't control this as a user, which is exactly why length is worth over-investing in: it's the one variable you fully control regardless of how well or poorly a given service protects its password database.
Complexity still matters — it's not either/or
Combine both and the payoff compounds: 12 characters using all four character types takes the crack time from 55 days (lowercase-only) to roughly 755,000 years at the same attack speed. Even against a dedicated cracking farm running a trillion guesses a second — a hundred times faster than the fast-GPU scenario above — that same 12-character mixed password still holds for roughly 7,500 years. At 16 characters, the numbers stop being meaningfully different from "never."
What this doesn't cover
Entropy math assumes every character is chosen uniformly at random. A real password built from a dictionary word, a name, or a keyboard pattern carries far less actual entropy than its length and character set suggest, because attackers try likely passwords first, not the full random space — a leaked-password dictionary attack finds "P@ssw0rd123!" in the first few thousand guesses regardless of what its theoretical entropy says. Use a password manager to generate genuinely random strings, and treat this calculator's numbers as a ceiling, not a guarantee.
The same caveat applies in reverse to passphrases: four truly random dictionary words (say, from a list of 7,776 words, the classic Diceware wordlist size) give roughly 12.9 bits of entropy per word, so a 4-word passphrase carries about 51.6 bits — respectable, comparable to an 8-character mixed password, but noticeably less than its raw 20-character length might suggest if you mentally applied the per-character formula instead of the per-word one. A 6-word random passphrase (about 77.5 bits) closes that gap and remains genuinely easy to remember and type.
Practical guidance, in order of impact
- Use a password manager to generate and store genuinely random passwords — this alone solves the "real passwords aren't actually random" problem above.
- Prioritize length over cleverness for any password you do generate or memorize yourself — 14–16 characters, mixed if you can manage it, plain if that's what you'll actually remember correctly.
- Never reuse a password across services — a single breach anywhere then compromises every reused account, regardless of how strong that one password is.
- Enable two-factor authentication wherever it's offered — it protects you even in the (common) event the password itself leaks somewhere you never find out about.
FAQ
Is a longer, simpler password really better than a shorter, complex one?
Per the entropy math above, generally yes — length multiplies the keyspace exponentially while adding a character type only multiplies the per-character options, so length wins for equal added effort in most realistic comparisons.
Why does the same password show wildly different crack times in different tools?
Because the assumed attacker speed differs — a tool assuming a rate-limited online attack (1,000 guesses/sec) will show a vastly longer crack time than one assuming an offline fast-GPU attack (10 billion/sec) for the identical password.
Does adding a symbol at the end of a normal word actually help much?
Marginally — it adds a small amount of entropy but doesn't fix the underlying problem that a dictionary-word-based password isn't drawn from the full random keyspace an attacker's dictionary-and-rules attack already anticipates.
How does this relate to a smart lock's PIN or account password?
Directly — a smart lock's app account is guarded by exactly this math, and its keypad PIN is guarded by a related but distinct fixed-length numeric-only version; see the keypad brute-force math for that comparison.
Is it safe to write passwords down instead of memorizing them?
A password physically written down and kept somewhere secure (not on a sticky note on the monitor) is often safer in practice than a memorized-but-weak password reused everywhere — the realistic threat to a written password is physical access to your home, a much narrower exposure than an online credential-stuffing attack against a reused weak password.
Where this matters beyond your email
The same math protects the account behind any app-controlled smart lock — see mechanical vs. smart deadbolts — and it's the foundation of the account-security half of whether smart locks can actually be hacked.