How long would it take to crack your password?

"This password would take 3 million years to crack" is a satisfying thing for a strength meter to say, but it hides every assumption that matters: cracked by whom, on what hardware, against which kind of system? Change those assumptions and the same password's crack time swings from millennia to milliseconds. This post puts real numbers on it.

The two attacks, and why they differ by a factor of a billion

When people say "crack a password," they mean one of two very different situations.

Online attacks go through the front door — the actual login form. The attacker is limited by network round-trips, rate limiting, lockouts, and CAPTCHAs. Realistic speed: somewhere between a few and a few thousand guesses per second, and any competent service locks the account long before that matters. Online guessing only works against the worst passwords: 123456, password, a pet's name.

Offline attacks are the real threat model. A service gets breached, its password database leaks, and the attacker now holds your password's hash — a fingerprint they can test guesses against on their own hardware, with no rate limit, as fast as their GPUs will go. Every crack-time figure you've ever seen quoted assumes this scenario.

How fast is offline? It depends almost entirely on which hashing algorithm the breached service used:

• MD5 or SHA-1 (legacy, sadly still common): a single modern GPU tests tens of billions of guesses per second. A rig of eight does hundreds of billions.
• bcrypt or scrypt (good practice): deliberately slow by design — the same hardware manages tens of thousands of guesses per second, a million times slower.
• Argon2 (current best practice): slower still, and memory-hard, which neuters GPU advantages.

You don't get to choose what a service hashes with, and you won't know until the breach notice arrives. So the conservative move is to assume the fast case: roughly 10 billion guesses per second on attacker hardware. That's the assumption behind the numbers below, and behind our password strength checker.

The table: length and variety vs. crack time

For randomly generated passwords (the "randomly" matters — see the next section), at 10 billion guesses/second, average time to crack:

| Password | Pool | Combinations | Average crack time | | --- | --- | --- | --- | | 6 digits (a PIN) | 10 | 10⁶ | instant | | 8 lowercase | 26 | ~2×10¹¹ | ~10 seconds | | 8 mixed + digits + symbols | 94 | ~6×10¹⁵ | ~3.5 days | | 10 mixed + digits + symbols | 94 | ~5×10¹⁹ | ~85 years | | 12 lowercase only | 26 | ~10¹⁷ | ~55 days | | 12 mixed + digits + symbols | 94 | ~5×10²³ | ~750,000 years | | 16 mixed + digits + symbols | 94 | ~4×10³¹ | longer than the age of the universe | | 4 random Diceware words | 7,776 | ~4×10¹⁵ | ~2.5 days | | 5 random Diceware words | 7,776 | ~3×10¹⁹ | ~45 years | | 6 random Diceware words | 7,776 | ~2×10²³ | ~350,000 years |

Two things jump out. First, length dominates: twelve lowercase letters beat eight characters of full keyboard-mashing complexity. Second, the jump between adjacent rows is enormous — each added character or word multiplies the work, it doesn't add to it. The difference between "3.5 days" and "750,000 years" is four characters.

(If you want the math behind these numbers — bits of entropy, why the alphabet sits inside a logarithm — we've worked through it in password entropy explained.)

Why "Summer2024!" cracks in seconds despite the table

Here's the part strength meters historically got wrong. The table above is for random passwords. Humans don't produce random passwords; they produce passwords drawn from a much smaller mental space — and attackers model that space directly.

Real cracking runs don't count up from aaaaaaaa. They start with wordlists built from previous breaches (billions of real human passwords are public), then apply mangling rules: capitalize the first letter, append a year, swap a for @, add a !. Summer2024! is eleven characters from a 94-symbol pool — naively ~2 million years — but it's also a dictionary word + current year + the most common suffix character, which a rules engine reaches within the first few minutes of a run. Its effective strength is maybe 25 bits, not 70.

The pattern generalizes: if a password has a story you can tell ("my dog's name plus my birth year, with the s as a 5"), the cracker has heard the story. Keyboard walks (qwerty, 1qaz2wsx), dates, names, song lyrics, and leetspeak substitutions are all in the first wave of guesses. A password that has ever appeared in a breach is effectively pre-cracked — it's literally on the list they try first.

What actually moves you to the slow end of the table

Two changes, in order of importance:

1. Let a machine pick the password. Randomness is the entire defense. A password generator drawing from a cryptographic RNG produces passwords whose real strength matches the table; a human brain does not. For passwords you must remember and type — your laptop login, your password manager's master password — a Diceware-style passphrase of five or six random words gives you table-grade strength that's actually memorable.
2. Make every password unique. Crack time is irrelevant if the attacker doesn't need to crack anything — credential stuffing (replaying a password leaked from site A against sites B through Z) is far more common than brute force. Unique passwords contain the damage of any single breach. This is only practical with a password manager, which conveniently also solves problem 1.

After those two, enable two-factor authentication on anything important: it turns "cracked your password" from game-over into a speed bump.

Checking where you stand

If you want to see the math applied to a real candidate, the password strength checker estimates entropy, applies the 10-billion-guesses-per-second worst case, and reports a crack time — entirely in your browser. Nothing you type is sent anywhere, which is the only acceptable architecture for a tool you paste passwords into. (Never paste a real, in-use password into a website that processes it server-side — test a structurally similar candidate instead.)

The one-line summary: assume the breach, assume fast hashes, and make your password something no rules engine can reconstruct — long, random, and used exactly once.