Most password advice is outdated. Mandatory symbols, 90-day rotation, “must contain one uppercase and a number”: NIST dropped all of it from SP 800-63B in 2017, and the guidance has only gotten firmer since. Length and randomness win; composition rules and forced rotation mostly produce worse passwords. Strong passwords are not a vibes question. There is a number that tells you how strong a password is, and you can compute it by hand.
Entropy, measured in bits
The strength of a password is its entropy: the number of independent random choices that went into making it. Information theory measures entropy in bits, and the formula is simple. If every character is drawn uniformly from an alphabet of size N, and the password is L characters long, the entropy is:
H = L × log2(N)Each bit of entropy doubles the number of guesses an attacker needs. Ten bits means roughly a thousand guesses (2^10 = 1,024). Twenty bits means about a million. Sixty bits means a million million million, past what a single fast GPU can brute-force in a reasonable time.
Work an example. A four-digit PIN uses an alphabet of 10 digits, so each character is log2(10) ≈ 3.32 bits. Four characters: 4 × 3.32 ≈ 13 bits of entropy. That’s only 10,000 possible PINs (0000 through 9999). That is why a phone can rate-limit a 4-digit lock screen into uselessness; the space is tiny.
An eight-character password drawn from uppercase (26), lowercase (26), digits (10), and common symbols (about 32) gives an alphabet of 94. log2(94) ≈ 6.55 bits per character, so eight random characters is about 52 bits, around 4.5 quadrillion combinations. A modern rig doing tens of billions of guesses per second eats it in hours.
The lesson hides in plain sight: entropy grows linearly with length, but only logarithmically with alphabet size. Doubling the alphabet adds one bit per character. Doubling the length doubles the bits. Length is the cheap knob.
Length vs complexity: the xkcd insight, updated
The xkcd comic “correct horse battery staple” made the case in 2011: four random common words are easier for a human to remember and harder for a machine to guess than the standard Tr0ub4dor&3 style. The math was right. Four words from a ~2,000-word list is 4 × log2(2048) = 44 bits of entropy, and “correct horse battery staple” is genuinely easier to recall than a mangled eight-character string.
Then NIST made it official. SP 800-63B tells verifiers to drop mandatory composition rules, drop periodic rotation, and accept passwords up to at least 64 characters. The reasoning is empirical: composition rules push users toward predictable substitutions (a → @, o → 0, e → 3) that attackers model first. Forced rotation makes people cycle through Spring2024!, Summer2024!, Fall2024!. Both rules shrink the real entropy of the password space.
Length is the lever the spec actually pulls on. A 16-character lowercase passphrase has 16 × log2(26) ≈ 75 bits. A 20-character one has about 94 bits, which is well into “infeasible offline” territory. The xkcd passphrase only works if the words are chosen randomly, say by dice rolls against a published wordlist. Picking four words yourself, where they “sound good together,” collapses the entropy fast.
Why random beats memorable
Here is the catch with human-chosen passwords: people are bad at random. When asked to invent an eight-character password with a symbol, millions of people produce something within edit distance two of Password1!. Real-world breach datasets (RockYou, Collection #1, the LinkedIn dump) show the same long-tail distribution: a few hundred templates account for an outsized share of all passwords ever used.
Attackers don’t brute-force the whole space. They run dictionary attacks, then mangling rules on top (capitalize first letter, append year, leet substitutions), then credential-stuffing with the half-billion passwords already public. Against that workload, a password that “feels” random but follows a template is much weaker than its nominal entropy suggests. P@ssw0rd2024! technically draws from a 94-symbol alphabet, but it lands in the first few seconds of any cracker’s run.
This is the real argument for generated passwords. A CSPRNG picking 16 characters uniformly from the printable ASCII set really does have 105 bits of entropy, because the choice is unbiased. You don’t have to remember it; the manager does, and there’s no template for an attacker to model.
Password managers and the unique-per-site rule
Reuse is the actual killer. Once you reuse a password across two services, the weaker service’s breach hands the attacker the key to the stronger one. The Have I Been Pwned corpus has billions of pairs, and credential-stuffing scripts are cheap to run. A single reused password turns one breach into a rolling compromise.
A password manager fixes this in the only way that scales: one strong master passphrase (a four-or-five-word diceware phrase, written down on paper in a drawer), and a unique generated password for every other account. The manager handles length, randomness, per-site uniqueness, and the fill-in. You stop being the entropy source, which is the whole point.
Browser-native managers like Apple Keychain, Bitwarden, 1Password, and the Chrome and Firefox built-ins are all fine. Use whichever one runs on every device you own. The best manager is the one you’ll actually keep installed.
Generate one
Stop trying to invent passwords. Run the Password Generator, set it to 20 characters with mixed sets, and use the output for any account that matters. Regenerate per site, store it in a manager, move on. The generator’s randomness is better than yours, and it doesn’t get tired.
One adjacent note on storage. The passwords sitting in a service’s database are not stored as passwords; they’re run through a one-way hash function like bcrypt, scrypt, or Argon2. Hashing is not reversible: given the hash, you can’t recover the original, you can only check guesses by hashing them and comparing. If you want to see what a hash looks like, the Hash Generator computes SHA-256, SHA-3, and friends over arbitrary input. Hashes are for verifying integrity and storing verifier material, not for encrypting a password you want to reuse later.
FAQ
How long does a password actually need to be?
For an online account that rate-limits login attempts, 12 to 16 random characters is comfortably out of reach of online guessing. For anything that could be hashed offline (a stolen database, an encrypted backup, a wallet seed), aim for 20+ random characters, or a six-word diceware passphrase. Both land you near or above 80 bits of entropy, which is the practical floor for offline threats.
Is a passphrase really as strong as a random string?
Per bit of entropy, yes. Four random words from a 2048-word list is 44 bits; six is 66 bits. The catch is the word selection must be random, generated by dice or a CSPRNG against a published list. Words you “picked because they sounded good” are not random and lose most of their claimed entropy.
Should I change my passwords on a schedule?
NIST SP 800-63B says no, and modern policy is to require a change only on suspected compromise. Forced rotation makes people choose weaker passwords: Winter2024! becomes Spring2024! because they’re optimizing for memorization, not strength. Keep a strong unique password per site until you have a reason to rotate.