Most password advice from a decade ago (mix uppercase, lowercase, a digit, a symbol) optimizes for the wrong thing. It produces passwords that are hard for humans to remember but not especially hard for a computer to guess. People respond to that rule in predictable ways: capitalize the first letter, swap "a" for "@", add "!" at the end. Attackers know these patterns and build them into their guessing tools.
The result is a strange mismatch. Two passwords can look equally "strong" to a human eye — both eight-plus characters, both with a capital letter, a digit, a symbol — yet be wildly different in actual security. One might take a laptop a few minutes to crack; the other might take longer than the age of the universe. The difference isn't visible from the password itself. It's in how the password was generated.
What actually makes a password hard to crack: entropy
Entropy measures how many possible passwords an attacker would have to try before finding yours, expressed in bits. It's a function of two things: how many characters are in your alphabet (lowercase-only vs. lowercase+uppercase+digits+symbols) and how long the password is. Doubling the alphabet size adds one bit per character. Adding one more character multiplies the total search space by the alphabet size, which is why length dominates.
A random 8-character password using upper, lower, digits, and symbols (a 94-character alphabet) has about 52 bits of entropy. A random 16-character password using only lowercase letters (26-character alphabet) has about 75 bits — stronger, despite the "simpler" alphabet, purely because it's longer.
Bits translate directly into guessing time, and it's worth seeing the actual numbers rather than taking "more entropy is better" on faith. When benchmarking cracking rigs against leaked hash dumps, a single modest consumer GPU (an RTX 3080-class card, using hashcat) can push roughly 30 billion guesses per second against a fast, unsalted hash. Run that against every possible 8-character password from a full 94-character alphabet (about 6×1015 combinations, 52 bits) and it falls in a little over two days. Add three more random characters to get to 11 characters from the same alphabet (about 5×1021 combinations, 72 bits) and the same rig needs roughly 5,000 years. Three extra characters, twenty bits, five orders of magnitude in cracking time — that's what "length dominates" looks like in real numbers, not just in theory.
This is also why "P@ssw0rd123" fails a real attacker despite technically satisfying most complexity checkers (uppercase, lowercase, digit, symbol, 11 characters). It isn't drawn from the full 9411 space of random combinations. It's a dictionary word with predictable substitutions applied. Cracking tools don't brute-force a password like that; they run a dictionary of common base words ("password", "welcome", "dragon", company names, sports teams) through a small set of mangling rules that try capitalizing the first letter, appending digits, and swapping letters for lookalike symbols (a→@, o→0, i→1, s→5, e→3). That whole ruleset gets tested against a word list in well under a second, because it's checking maybe a few million candidates, not quadrillions. A password that looks complex to a human but is structured like "word + case + suffix + substitution" collapses to almost nothing once an attacker knows the structure — and they always do, because it's the structure nearly everyone defaults to when told to "use a symbol and a number."
Why "correcthorsebatterystaple" works
This is the classic example from the XKCD comic that popularized the idea: four random common words, concatenated, produce a passphrase that's both long (high entropy) and genuinely memorable, unlike a random string of symbols. The catch is the word selection has to actually be random. A phrase you made up by thinking of "words that go together" has far less entropy than truly random word selection, because human-generated phrases follow predictable patterns.
The standard way to generate a real passphrase is diceware: roll physical dice (or use a cryptographic random number generator) to pick words from a fixed list, commonly the EFF's 7,776-word list. Each word picked this way carries about 12.9 bits of entropy (7,776 is 212.9). Four words gets you roughly 51.6 bits, comparable to that random 8-character full-alphabet password. Six words gets you to about 77 bits, comfortably past what's practical to brute-force with current hardware, while still being something you can actually memorize and type — four to six ordinary words rather than a string of unrelated symbols.
For anything you don't need to memorize (which, with a password manager, is almost everything), a fully random string beats a passphrase on entropy-per-character, since it packs more bits into fewer keystrokes. Passphrases exist specifically for the few passwords you do have to remember by heart, like a device unlock code or your password manager's master password. Both approaches are valid; they just solve different problems. Random strings are for machines to store and enter on your behalf, while passphrases are for the small number of cases where a human still has to type from memory.
The real fix: stop remembering passwords at all
The entropy debate matters most for the handful of passwords you have to type from memory. For everything else, a password manager generates and stores a long random password per site, so you never need to think about length or memorability at all. You just need one strong master password (ideally a passphrase) to unlock the manager itself.
This changes the whole calculus, not just the mechanics. Once you're not typing a password by hand, "memorable" stops being a design constraint at all: there's no reason to ever reuse a mental pattern, shorten a password so you can type it faster, or pick something close to a dictionary word "just this once." A password manager can default to 20+ random characters across the full symbol set for every single account, because the only thing that ever needs to recall it is the manager itself. Good managers store that vault client-side-encrypted, meaning even the company running the service can't read your stored passwords if their servers are breached — the encryption key is derived from your master password, which never leaves your device.
This also solves the more common real-world failure mode: password reuse. A strong-but-reused password is only as safe as the least secure site you used it on — if any one of them leaks its password database, every account sharing that password is compromised too. This is exactly how "credential stuffing" attacks work: an attacker takes a list of emails and passwords leaked from Site A (breach lists with billions of real credentials circulate on criminal forums) and automatically tries the same combinations against Site B, Site C, and Site D. It has nothing to do with how strong any individual password was. Reuse alone is the vulnerability. A unique random password per site, generated and stored by a manager, makes credential stuffing structurally impossible, since there's no second site where the same password would work.
Try it
GlaeKit's Password Generator uses your browser's cryptographic random number generator, with adjustable length and character sets. Nothing is sent to a server.
Frequently asked questions
How long should a password be?
At least 12–16 characters for most accounts if it's randomly generated; longer for anything especially sensitive. Many services now enforce a 64-character maximum, which is far more than needed. 16–20 random characters is already well beyond what's practical to brute-force.
Do I still need symbols and numbers if my password is long?
They help, but marginally, once length is already high. A 20-character random lowercase password is already extremely strong; adding digits and symbols pushes it further but the length is doing most of the work.
How often should I change my passwords?
Current guidance (including from NIST) is to stop forcing periodic changes — they tend to make people pick weaker, more predictable passwords to make the rotation less annoying. Change a password when there's a specific reason: a breach notification, suspicious activity, or reuse across sites you're now consolidating.
What is a dictionary attack, and why does it beat "complex" passwords?
A dictionary attack tries a list of likely passwords — common words, leaked passwords from other breaches, and predictable variations of both — instead of every possible character combination. Because it targets patterns humans actually use (a base word plus a capital letter, a trailing digit, and a symbol substitution), it can crack a "complex-looking" password like "P@ssw0rd123" in seconds, even though the same length of truly random characters would take thousands of years. It beats complexity rules because it exploits how predictably humans satisfy them.
Are passphrases actually as secure as random strings?
Yes, as long as the words are chosen randomly (typically from a fixed word list via dice or a random number generator) rather than picked by a person. A six-word random passphrase carries roughly 77 bits of entropy, on par with a 13-character fully random password, and it's far easier to type and remember. A passphrase you invented by thinking of words that "sound good together" is much weaker, because that mental process is itself predictable.