“Must contain uppercase, number and symbol” — I watched a colleague satisfy that rule with “Autumn2024!” and get breached in months. The rule measured the wrong thing. What makes a password strong is length (search-space size), unpredictability (uniform randomness), uniqueness (one site, one secret) and screening (not in breach lists) — complexity checklists rank a distant fifth. Here is the physics, with the mandated entropy table.
Part of the password generator guide. Test ratings privately in the password strength tester; developers can fingerprint secrets with the hash generator (hashes, never plaintext).
Length and entropy: the only table that matters
Bits = length × log2(pool). Order-of-magnitude framing only — illustrative offline attack ≈10 billion guesses/sec; throttled online logins are vastly slower; dictionary attacks beat brute-force math, so treat these as ceilings:
| Password type | Entropy | Illustrative offline scale |
|---|---|---|
| 8 chars, lowercase | 37.6 bits | Minutes — never use |
| 12 chars, full 94-pool | 78.7 bits | Impractical — decent minimum |
| 16 chars, full pool | 104.9 bits | Effectively uncrackable by brute force |
| 5-word EFF passphrase | 64.6 bits | Strong + memorizable |
Each added full-pool character multiplies search space ~94×; each added word multiplies ~7,776×. That compounding is why length wins every argument against complexity theater.
Beyond bits: unpredictability, uniqueness, screening
- Unpredictability: uniform draws from crypto.getRandomValues — human “random” (birthdays, lyrics, keyboard walks like qwerty123) collapses entropy regardless of length. Test how meters judge this in strength tester guide.
- Uniqueness: a 104-bit secret reused on 10 sites has 104-bit strength exactly once — the first breach burns all ten. Breach priority order in breach checklist.
- Screening: NIST requires checking creations against breach corpora, dictionaries and service names. “Correct-Horse-9!” looks strong and sits in every cracker dictionary — screening catches what math cannot.
- Composition rules considered harmful: forced symbols push everyone to the same predictable slots (capital first, 123! last). NIST dropped composition mandates; length + screening replaced them.
The memory tradeoff (why passphrases exist)
Humans cannot hold 104 bits of gibberish — so the memorable tier exists: 5–6 random EFF words (~64.6 bits at 5) for master passwords and the two secrets you memorize, random 16+ strings for everything a manager holds. Never downgrade stored secrets to memorable ones “to be safe” — the manager removes the memory constraint, so use full randomness there. Choosing between them per account in passphrase vs password; memorizing safely in remembering guide.
Why site policies still demand nonsense (and how to comply)
If length beats complexity, why do banks still require “one symbol, changed every 90 days”? Legacy compliance checklists, audit inertia, and regulators who codified 2003-era advice. You cannot fix their policy; you can comply cheaply: satisfy the form with a long generated secret that happens to include a symbol (length carries you regardless), set a calendar note for their forced rotation, and treat that account as weaker-by-policy — extra MFA, unique secret, closer monitoring. Never let one site's bad rules infect your system: keep personal vault on NIST-grade practices, maintain a mental “weak-by-policy” list (usually 2–3 legacy banks), and favor institutions with modern auth (passkeys, app-2FA) when choosing where to bank next.
General information only, not security advice. Generate offline, store in a manager, enable MFA on email/bank. If you lose your master password it cannot be recovered by us.