Password Rules Are Mostly Wrong: Entropy, Passphrases and What NIST Now Says

Why "P@ssw0rd1!" is a bad password and "correct horse battery staple" is not

Most password advice you have been given is a decade or more out of date. The rules that dominated the 2000s — one uppercase, one number, one symbol, change it every ninety days — were not derived from measurement. They were a plausible-sounding guess, they became policy, and they turned out to make passwords worse.

In 2017, the US National Institute of Standards and Technology rewrote its own guidance and reversed most of it. NIST Special Publication 800-63B now recommends against mandatory composition rules, against mandatory periodic rotation, and in favour of length and screening against known-breached passwords. That guidance is nearly a decade old at this point and still has not filtered down to most of the forms you fill in.

This article explains why the reversal happened, and what to do instead.

Entropy: the only measure that means anything

Password strength is measured in bits of entropy — a count of how many guesses an attacker needs, expressed as a power of two. Add one bit and you double the work.

The formula is straightforward. If a password is drawn randomly from an alphabet of N possible symbols and is L symbols long, its entropy is L × log₂(N).

• Lowercase only (26 characters): about 4.7 bits per character.
• Lower + upper (52): about 5.7 bits.
• Lower + upper + digits (62): about 5.95 bits.
• All printable ASCII (94): about 6.55 bits.

Notice how little the alphabet matters. Going from lowercase-only to the full symbol set gains you about 1.9 bits per character. Adding two more lowercase characters gains you 9.4 bits. Length beats complexity, and it is not close.

An 8-character random password using every symbol on the keyboard is about 52 bits. A 12-character random lowercase password is about 56 bits — stronger, and vastly easier to type on a phone.

That word random is doing enormous work in these calculations, and it is where human-chosen passwords fall apart.

The word "random" is where human passwords collapse

The entropy formula assumes every symbol was chosen with equal probability, independently. Humans do not do that.

Take P@ssw0rd1!. Ten characters, uppercase, lowercase, digit, two symbols. It satisfies every composition rule any website has ever imposed. By the naive formula it is about 65 bits.

Its actual entropy is close to zero, because it is not a random string. It is the word "password" with four utterly predictable transformations applied:

1. Capitalise the first letter — the overwhelmingly most common place people capitalise.
2. Substitute @ for a and 0 for o — leetspeak substitutions that every cracking tool has built in as a standard ruleset.
3. Append a digit at the end — again, by far the most common position.
4. Append ! — by far the most common symbol, in by far the most common position.

Password crackers do not iterate blindly through the keyspace. They start from wordlists of hundreds of millions of real passwords harvested from breaches, then apply mangling rules that encode exactly these habits. P@ssw0rd1! falls within the first few million guesses. On commodity hardware, that is measured in fractions of a second.

This is the core insight NIST acted on: composition rules do not force unpredictability, they force a predictable pattern. Tell a hundred million people to add a number and a symbol, and you get a hundred million passwords ending in 1!. You have not expanded the search space; you have told the attacker where to look.

Passphrases, and the actual arithmetic

The alternative that both survives cracking and survives being remembered by a human is a passphrase: several unrelated words chosen at random.

Suppose you pick from a list of 7,776 words — the size of a standard Diceware list. Each word contributes log₂(7776) ≈ 12.9 bits:

• Four words: about 51.7 bits.
• Five words: about 64.6 bits.
• Six words: about 77.5 bits.
• Seven words: about 90.4 bits.

A crucial point that trips people up: this figure holds even if the attacker knows exactly which wordlist you used and how many words you picked. The security lives entirely in the random selection, not in secrecy about the method. Five words from a known 7,776-word list is still 7,776⁵ ≈ 28 quadrillion combinations.

The catch — and it is absolute — is that you must not choose the words. If you pick words that feel unrelated, you will unconsciously produce a phrase with grammatical structure, thematic coherence, or personal meaning, and each of those collapses the search space by orders of magnitude. correct horse battery staple is strong because dice chose it. my favourite dog is Rex is weak despite being longer, because a human chose it and it is a sentence.

Use something that actually generates randomness — physical dice, or a generator that draws from the browser's cryptographic random source. Our Password Generator uses crypto.getRandomValues(), the browser's CSPRNG, rather than Math.random(), which is not designed for anything security-related and should never be used to generate a secret.

How much entropy is enough?

It depends entirely on how the password is stored on the other end — which you generally cannot know. So plan for the bad case.

If a service hashes passwords properly with a modern algorithm designed to be slow and memory-hard — bcrypt, scrypt, or Argon2 — offline guessing is expensive, and around 60 bits is genuinely comfortable.

If a service uses a fast general-purpose hash such as unsalted SHA-256, a single modern GPU can test billions of candidates per second. If it stores passwords in plain text, entropy is irrelevant the moment it is breached.

Reasonable targets:

• Throwaway accounts you would not care about losing: 50 bits. Four random words, or 10 random characters.
• Ordinary accounts — shopping, forums, most services: 65 bits. Five random words, or 14 random characters.
• Important accounts — email, banking, cloud storage: 80 bits. Six random words, or 16+ random characters. Email deserves special weight, because it is the reset channel for everything else.
• Master password for a password manager, or full-disk encryption: 90+ bits. Seven random words. This one you memorise; everything else, the manager remembers.

What NIST reversed, and why

Mandatory 90-day rotation. The reasoning was that a stolen password expires. In practice, forced rotation makes people pick weaker passwords and mutate them predictably — Summer2025! becomes Autumn2025!. An attacker who has one of your passwords can guess the next few trivially. Current guidance: change a password when there is reason to believe it is compromised, not on a calendar.

Composition rules. Covered above — they produce predictable patterns rather than genuine unpredictability.

Security questions. Your mother's maiden name, your first school, your first pet. These are low-entropy, frequently public, often guessable by anyone who knows you, and unchangeable once leaked. If a service forces them on you, put random strings in the answers and store those in your password manager. There is no rule that the answers must be true.

Two things NIST recommends that most sites still do not do: screen new passwords against lists of known-breached ones, and allow long passwords and spaces. A maximum length of 16, or a rule against spaces, tells you something uncomfortable about how the password is being handled on the server.

Reuse is the actual threat

Everything above concerns how hard your password is to guess. But the most common way accounts are compromised has nothing to do with guessing.

It is credential stuffing. A small site with weak security is breached. The attacker takes the email/password pairs and replays them against hundreds of major services, automatically. If you used the same password on your email as on that forum, the strength of the password is irrelevant — nobody had to crack it.

This makes uniqueness at least as important as strength, and unique passwords for a hundred accounts are impossible to memorise. Which is what password managers are for: one strong memorised passphrase protecting a vault of long random unique strings you never see.

And enable two-factor authentication, at minimum on email and anything financial. An authenticator app or a hardware key is meaningfully better than SMS, which is vulnerable to SIM-swap attacks — but SMS 2FA is still far better than none.

A note on where your password is generated

If you use an online password generator, the password is a secret that must exist in exactly one place before you store it: your own machine.

A generator that runs on a server is generating your secret somewhere else and transmitting it to you. Even with the best intentions on the operator's side, that is a copy you cannot account for, travelling over a network, possibly appearing in a log.

Browsers have had a cryptographically secure random number generator built in for years. There is no technical reason to generate a password anywhere but locally. Our generator runs entirely in your browser — you can verify this by opening the network tab and watching that nothing is sent, or by disconnecting from the internet and confirming it still works.

The short version

1. Length beats complexity. A long lowercase passphrase outperforms a short symbol soup.
2. Let a machine choose the words. Human "randomness" is not random.
3. Never reuse a password. This matters more than strength.
4. Use a password manager, protected by one long memorised passphrase.
5. Turn on two-factor authentication for email and anything financial.
6. Stop rotating passwords on a schedule. Rotate them when something is actually wrong.
7. Lie in your security questions, and store the lies.