The mental picture most people have is a hooded figure typing guesses into a login box. That attack is real, and it is also the one every serious system already defeats: after five wrong attempts the account locks, the IP is rate-limited, and a second factor is demanded. An attacker gets a few hundred guesses at most.
The attack that matters happens somewhere else entirely, and it gets billions.
The attack that actually happens
A company is breached and its user database is copied. That database does not contain passwords — any competent system stores a hash of each one, a fixed-length fingerprint that cannot be reversed. What the attacker now has is a list of hashes, sitting on their own hardware, with no rate limit, no lockout and no logging.
They guess offline. Hash a candidate password, compare it against the list, repeat. The speed depends entirely on which hash function the company chose:
- MD5 or SHA-1 — tens of billions of guesses per second on a single modern graphics card. These are still found in breached databases.
- SHA-256, unsalted — billions per second. Fast is a virtue for checksums and a catastrophe for passwords.
- bcrypt, scrypt or Argon2 — a few tens of thousands per second, by design. These functions are deliberately slow and memory-hungry, which costs the server microseconds per login and costs the attacker a factor of a million.
You do not choose which of these protected you. That decision was made by whoever built the site, years ago, and you will never be told what they picked. This is the single most important fact about password security, and it argues for exactly one behaviour: never reuse a password, because you cannot know which sites will hand yours over.
Attackers do not guess randomly
Brute force — trying aaaa, aaab, aaac — is the last resort, not the first. The order of operations is:
1. Wordlists. Every password from every previous breach, compiled and sorted by frequency. Hundreds of millions of real passwords that real people chose. If yours has ever appeared in a leak, it is guess number one, and its length is irrelevant.
2. Rule-based mangling. Take each word and apply the transformations humans reliably apply. Capitalise the first letter. Append a digit. Append a year. Append an exclamation mark. Replace a with @, e with 3, o with 0. Standard rule sets contain tens of thousands of these, and they are applied to every word in the list.
This is why P@ssw0rd! is not a clever password. It is the word password with four of the most common rules applied, and it falls in under a second. The substitutions feel creative because you invented them yourself. Everyone invents the same ones.
3. Hybrid and mask attacks. A known word plus a four-digit year. Eight characters where the first is uppercase, the middle five are lowercase and the last two are digits. That is exactly the shape "must contain uppercase, lowercase and a number" forces people into. The complexity rules narrowed the search space instead of widening it.
4. Only then, brute force. And by this point most of the database is already cracked.
Why length beats complexity
Entropy — the number of possibilities an attacker must work through — is log₂(alphabet size) × length. Length multiplies. The alphabet is only inside a logarithm.
Adding symbols to a 95-character alphabet from a 62-character one buys you 0.6 bits per character. Adding one more character buys you 5.9 bits. Length wins by an order of magnitude, every time.
Concretely: an eight-character password using every symbol on the keyboard is about 52 bits. A sixteen-character password using only lowercase letters is about 75 bits. The second is roughly eight million times harder to crack, and vastly easier to type on a phone.
This is why a passphrase works. Four random words from a two-thousand-word list is about 44 bits; six words is 66 bits and you can say it out loud. The critical word is random — words you chose yourself are not, because human word choice clusters hard, and a phrase from a book or a song is in a wordlist already.
How long does it really take?
Take 100 billion guesses per second — a well-funded attacker against a fast hash. On average you crack a password after searching half the space:
- 8 characters, lowercase only — under a second
- 8 characters, mixed case and digits — about 3 minutes
- 8 characters, everything — about 3 hours
- 12 characters, mixed case and digits — about 30 years
- 16 characters, lowercase only — about 6 million years
Every one of those numbers assumes the password is not in a wordlist and follows no pattern. If it is, none of them apply and the answer is "instantly". You can run any of these through the strength checker, which does the arithmetic and separately flags the patterns the arithmetic cannot see.
What the advice got wrong
The rules most of us learned — eight characters, one uppercase, one number, one symbol, changed every ninety days — came from a 2003 document by Bill Burr at NIST. He has since publicly said he regrets it. The 2017 revision, NIST Special Publication 800-63B, reversed most of it, and the reasoning is worth reading:
- Composition rules are counterproductive. They push everyone towards the same predictable shapes, which is exactly what a mask attack exploits.
- Forced expiry makes passwords weaker. Someone made to change every ninety days picks
Summer2024!, thenAutumn2024!. Change it when you have reason to think it is exposed, not on a calendar. - Length should be encouraged and long passwords must be accepted. A site with a maximum length of sixteen characters is telling you something is wrong behind the scenes — a properly hashed password is a fixed size no matter how long the input was.
- Check against known-breached lists rather than imposing arbitrary character rules.
The salt, and why the same password differs
A salt is a random value stored alongside each hash and mixed in before hashing. Without it, identical passwords produce identical hashes — so an attacker cracks one and gets every account that shared it, and precomputed rainbow tables work. With a unique salt per user, every password must be attacked individually.
Salting is not optional and has not been for decades. When a breach report says "passwords were unsalted", it means the entire database fell at the speed of the most common password in it.
What to actually do
Use a password manager and a different password everywhere. This is the whole answer, and everything else is detail. Reuse is what turns one company's breach into your problem, and no amount of cleverness in a single password fixes it.
Let it generate them. Twenty random characters you never see is strictly better than anything memorable, because you are not going to type it. Reserve the memorable passphrase for the two you must know by heart: the manager's master password, and your device login.
Turn on a second factor wherever it is offered, and prefer an authenticator app or a hardware key over SMS, which is vulnerable to SIM swapping. A second factor means a cracked password alone is not enough.
Never type a real password into a strength checker that uploads it. The request goes to a server, over a network, into logs you cannot see. This is the one kind of tool where where it runs decides whether it is safe to use at all. This one and the generator run in your browser, and you can confirm it by disconnecting from the internet and watching them keep working.
The short version
Passwords are cracked offline, in bulk, at billions of guesses per second, starting from lists of real passwords and the predictable ways people modify them. Length beats complexity because it multiplies rather than adds. Reuse is the failure that turns someone else's breach into yours. Use a manager, make them long, and add a second factor.