What makes a password strong? Entropy, length and passphrases
Every password rule you've ever been forced to follow — one capital, one digit, one symbol — was an attempt to make you pick something hard to guess. It mostly produced P@ssw0rd1 and Winter2026, which professional cracking software tries in its first few seconds. This guide explains what attackers actually do with passwords, what "strength" really measures, why sheer length beats clever substitutions, and how a handful of genuinely random words can outclass the lot.
What attackers actually do
Nobody sits at a login page typing guesses. Login forms are slow, rate-limited, and quick to lock accounts — online guessing only catches people using a default or one of the few hundred most common passwords. The attacks that matter happen elsewhere.
Offline cracking. Websites don't (or shouldn't) store your actual password; they store a hash of it — a one-way fingerprint that can be checked but not reversed. When a site is breached, attackers walk away with that list of hashes and take it home. On their own hardware there are no rate limits: a rig of consumer graphics cards can test billions of guesses per second against a fast hash. And the guesses aren't blind — cracking software starts with wordlists distilled from every previous breach, then applies "mangling rules" that mimic human habits: capitalize the first letter, swap a for @, bolt a year on the end. You can see what a hash looks like by typing anything into the hash generator — one character changed, and the whole fingerprint changes.
Credential stuffing. The other workhorse attack needs no cracking at all: take the email-and-password pairs leaked from site A and replay them, automatically, against sites B through Z. If you reused the password, the attacker is in. Strength is irrelevant here; only uniqueness helps.
So a good password has exactly two jobs: survive an offline cracking run if the site's database leaks, and be unique so a leak elsewhere doesn't unlock it.
Entropy, in plain English
Password strength is a measure of one thing: how many possibilities an attacker has to grind through before yours turns up. Security people express that count in bits of entropy, and the idea is friendlier than it sounds — each bit doubles the number of possibilities. Ten bits is about a thousand options; twenty bits, about a million; forty bits, about a trillion.
Where do the bits come from? From random choices. One character picked at random from the 26 lowercase letters is worth about 4.7 bits (because 24.7 ≈ 26). Picked from the full keyboard of roughly 94 printable characters, about 6.6 bits. The crucial part: every extra random character adds the same number of bits, which means it multiplies the attacker's work by the same factor. Length doesn't nudge strength upward — it compounds it.
The equally crucial fine print: entropy measures the process that produced the password, not how the result looks. Tr0ub4dor&3 looks impressively noisy, but it was produced by a very human recipe — dictionary word, predictable swaps, punctuation at the end — and cracking rigs model exactly that recipe. A strength meter on a website can only guess how a password was made, usually generously. A generator that made the password itself can report the honest number, because it knows precisely how much randomness went in.
Why length beats substitution tricks
P@ssw0rd is in every cracking dictionary on earth — not as a curiosity, but because the rule engines were trained on breached corpora full of it. Substitutions feel clever because they're hard for you to remember; to software that applies every common swap to every dictionary word automatically, they add close to nothing. The same goes for the ritual capital-first-letter and digit-at-the-end: predictable positions add a bit or two, not the twenty you need.
Compare two passwords honestly. Eight truly random characters drawn from all four character classes give about 6 quadrillion possibilities. Twelve random lowercase-only letters give about 95 quadrillion — roughly fifteen times more work for the attacker, while being easier to type on a phone. The four extra characters beat the three extra character classes, and it isn't close.
This is also the direction official guidance has moved. NIST SP 800-63B, the US standard for digital identity, recommends that sites stop imposing composition rules ("must contain a symbol"), allow long passwords, screen new passwords against known-breach lists, and stop forcing scheduled password changes — because all of those pushed people toward predictable patterns.
Honest magnitudes: recipe vs time to crack
Exact "time to crack" numbers are mostly theater — the honest answer depends enormously on how the breached site hashed its passwords and how much hardware the attacker rents. But the orders of magnitude are real, and the ordering never changes. Assume the pessimistic case: a leaked database, a fast hash, serious hardware.
| How the password was made | Example shape | Offline cracking outlook |
|---|---|---|
| Any breached password, with swaps | P@ssw0rd1, Winter2026 | Gone in the first seconds — these are tried first |
| 8 random lowercase letters | kqzvwmel | Seconds |
| 8 random characters, all classes | rV4$wq#8 | Hours to days |
| 10 random characters, all classes | m$8Kw2&pQz | Years to centuries |
| 12 random characters, all classes | gW5#nq$8Vz2m | Thousands of years |
| 16 random characters, all classes | what a manager autofills | Effectively unreachable |
| 4 random words from a large list | brisk-ferry-oat-plume | Hours to days — about the same as 8 random characters |
| 6 random words from a large list | a manager's master passphrase | Thousands of years |
Two footnotes to keep the table honest. First, it assumes the attacker knows your recipe and only has to search the random part — the safe assumption, since recipes are shared by millions of people. Second, a site that stores passwords with a deliberately slow hash (bcrypt, scrypt, Argon2) shifts every row up by several orders of magnitude. You don't get to choose which sites do that, so build passwords for the bad case.
Four random words, done right
The famous xkcd comic proposed correct horse battery staple: four common words, easy to remember, long enough to be strong. The idea is sound, and it comes with one non-negotiable condition that most people quietly drop: the words must be chosen at random, not by you. Words you pick yourself cluster around favorites, song lyrics and quotations — all of which live in cracking wordlists, which run combinator attacks over common word pairs and phrases all day. (For that matter, correcthorsebatterystaple itself is in the lists now.)
Done properly, you let dice or a cryptographic random generator draw each word from a large list. The classic "diceware" lists hold 7,776 words, so every word drawn adds about 12.9 bits — four words land near 52 bits, and six words near 77, matching a 12-character fully random password while remaining something a human can actually type and remember. Word count is the lever that matters; capitalizing or bolting a digit on the end mostly just satisfies form validators.
Try it: the password generator has a memorable-words mode that draws every word with your browser's cryptographic random generator, locally — and its meter reports the honest bit count as you add words, so you can watch length do the work that decoration can't.
Reuse is the biggest sin
A perfectly random password reused on thirty sites is a single point of failure with excellent branding. The moment any one of those thirty is breached, credential stuffing turns the other twenty-nine into open doors — no cracking required, no warning given. Uniqueness protects you from other people's security mistakes, which are the mistakes you can't prevent.
Since no one can memorize a hundred unique random passwords, the practical system is: one password per site, generated at 16-plus random characters, stored in a password manager. Built into your browser or standalone — the important war is manager versus reuse, not one brand versus another. Managers add a quiet second benefit: they fill passwords only on the exact domain they were saved for, so a convincing look-alike phishing site gets nothing. You're left memorizing perhaps three secrets: your device unlock, your email account, and the manager's master passphrase — which is precisely where those six random words belong.
And when you genuinely need to hand a password to another person, don't paste it into chat or email, where it will be stored and searchable for years — that problem has its own guide: how to share a password or secret safely, and a purpose-built tool in the one-time link.
What strength can't fix
Entropy defends against exactly one attack: guessing. It's worth being clear about what it does nothing for. A phishing page that convinces you to type your password gets all 128 bits of it. An infostealer on your laptop reads every saved password at once. A site that stores passwords in plaintext, or logs them by accident, wastes your randomness entirely. And attackers who can trigger a weak password-reset flow — say, one gated only by SMS — walk around the password rather than through it.
That's the case for two-factor authentication on anything you'd mind losing: any second factor beats none, and an authenticator app or hardware key beats codes sent over SMS. Strength is necessary, not sufficient.
Where this is heading: passkeys
The long-term fix is to stop sharing secrets with websites at all. A passkey is a cryptographic key pair: the site stores the public half, your device keeps the private half and uses it to sign a login challenge after you unlock with a fingerprint, face or PIN. There's nothing reusable for a breach to leak, nothing to guess, and nothing a look-alike site can phish, because the key is bound to the real domain. Support is now built into the major platforms and browsers, and sites are adopting it steadily. Passwords will still be with us for years, though — so until the last one retires, the playbook stands: long, random, unique, kept in a manager.
Related: How to share a password or secret safely · Checksums: how to verify a downloaded file is genuine · Why Toolkit runs entirely in your browser