How to Create a Strong Password (and Why Length Beats Complexity)

Almost everything you were taught about passwords is wrong. The rules that demand an uppercase letter, a number, and a symbol — the ones that reject your password until it looks like P@ssw0rd! — make passwords harder to remember and easier to crack. They optimize for the wrong thing. The math is not subtle, and the U.S. government's own standards body reversed its advice years ago to match it.

This guide gives you the rule that actually matters, the arithmetic behind it, and the specific mistakes that turn a "complex" password into a weak one. Every number here is reproducible — you can check the entropy yourself.

TL;DR: what makes a password strong?

A strong password is long and random. Length adds resistance to guessing faster than special characters do, because every extra character multiplies the number of possibilities an attacker must try. A 5-word random passphrase like correct-horse-battery-staple-river is both easier to remember and dramatically harder to crack than P@ssw0rd!. The single most important rule: make it long, make it unique to that one site, and let a password manager remember it. Forced symbols and 90-day rotation are obsolete advice that the NIST SP 800-63B guidelines explicitly tell sites to stop requiring.

The two questions that decide a password's strength:

1. How many guesses does an attacker need? That is entropy, measured in bits. More bits = exponentially more guesses.
2. Is it reused anywhere? A password used on two sites is only as safe as the weakest site that stores it.

Everything below is the detail behind those two answers.

How password strength is actually measured: entropy

Password strength is measured in bits of entropy — the base-2 logarithm of how many distinct passwords could have been generated by the same process. The formula for a randomly generated password is:

entropy (bits) = length × log2(charset_size)

where charset_size is how many characters could appear at each position:
  digits only        = 10
  lowercase only     = 26
  lower + upper      = 52
  lower + upper + digits = 62
  full printable ASCII   = 95   (95 printable characters on a US keyboard)

Each bit of entropy doubles the number of guesses an attacker must make on average. 40 bits means ~1 trillion possibilities; 60 bits means ~1 quintillion. The jump is exponential, which is why small changes in length swing the result enormously.

Crucially, this formula only holds when the password is chosen randomly. A human picking Summer2025! is not sampling uniformly from 95^11 possibilities — they are sampling from a tiny, predictable subset that attackers model directly. Entropy measures the generation process, not the characters that happen to be present.

Worked example: 16 random characters vs a 4-word passphrase

Two ways to reach roughly the same strength — one you can't type from memory, one you can:

Random 16-char password from full printable ASCII (95 symbols):
  entropy = 16 × log2(95)
          = 16 × 6.5699
          ≈ 105.1 bits
  Example: t7$Kq!9aR#mP2vZx   (unmemorable; needs a manager)

4-word Diceware passphrase from the 7,776-word EFF list:
  entropy = 4 × log2(7776)
          = 4 × 12.925
          ≈ 51.7 bits
  Example: anchor-pottery-jukebox-drizzle

5-word Diceware passphrase:
  entropy = 5 × log2(7776) ≈ 64.6 bits
  Example: anchor-pottery-jukebox-drizzle-meadow

6-word Diceware passphrase:
  entropy = 6 × log2(7776) ≈ 77.5 bits   (memorable AND very strong)

Now compare those to the "complex" password everyone is forced to make:

"P@ssw0rd!" treated as a random 9-char string (the optimistic case):
  entropy = 9 × log2(95) ≈ 59.1 bits  ← on paper, looks fine

But it is NOT random. It is "password" + predictable leet substitutions:
  - "password" is the #1 entry in every breach corpus (rockyou, HIBP)
  - @→a, 0→o, !→ append are the first rules every cracker tries
  Real-world guessing strength: a few bits. Cracked in milliseconds.

That is the whole argument in four code blocks. The 6-word passphrase you can memorize (~77 bits) is stronger than the symbol-stuffed password you can't (~0 effective bits, because it is a dictionary word with cosmetic edits).

Entropy vs length vs crack time

The table below uses offline attack speeds, where an attacker has stolen a password database and guesses locally. The realistic range: a fast GPU on an unsalted SHA-1 hash does roughly 10^10 (10 billion) guesses/second, while a properly chosen slow hash like bcrypt caps attackers near 10^4 (10,000) guesses/second. Times below assume the fast SHA-1 GPU case — the worst case for the defender — using the same model as our password strength meter.

| Password | Charset | Length | Entropy | Time @ 10^10 guesses/s | |----------|---------|--------|---------|------------------------| | hunter2 | lower+digit (36) | 7 | ~36 bits | instant (< 1 second) | | Tr0ub4dor | mixed (62) | 9 | ~54 bits | ~1.7 days | | 12 random lowercase | 26 | 12 | ~56 bits | ~7 days | | anchor-pottery-jukebox-drizzle (4 words) | Diceware | — | ~52 bits | ~10 hours | | 12 random full-ASCII | 95 | 12 | ~79 bits | ~290,000 years | | 5-word Diceware | 7,776-word list | — | ~65 bits | ~120 years | | 16 random full-ASCII | 95 | 16 | ~105 bits | ~10^15 years | | 6-word Diceware | 7,776-word list | — | ~78 bits | ~150,000 years |

Two things jump out. First, length dominates: doubling a random password from 8 to 16 characters does not double its strength — it squares the number of guesses. Second, a passphrase made of common dictionary words reaches multi-century crack times purely through length, no symbols required.

You can verify any of these yourself by typing a candidate into the password strength meter — it computes entropy and crack times entirely in your browser, with nothing sent over the network.

Why "complexity rules" backfire

For two decades the standard advice — codified in NIST's 2003 guidance, written by Bill Burr, who later publicly apologized for it — was: mix character classes and rotate every 90 days. Both rules are now considered actively harmful, and NIST removed them.

The current NIST SP 800-63B Digital Identity Guidelines (Section 5.1.1, reaffirmed through the 2024–2025 -4 revision) tell verifiers the opposite. The relevant requirements, paraphrased from the spec:

• Allow at least 64 characters. Length is the primary strength lever, so don't cap it low.
• Accept all printable ASCII and spaces (and ideally Unicode). Banning characters shrinks the keyspace and blocks passphrases.
• Do NOT impose composition rules. Forcing "1 upper, 1 digit, 1 symbol" pushes users toward predictable patterns like Password1!.
• Do NOT require periodic rotation. Force a change only on evidence of compromise. Mandatory rotation makes users pick weaker, incremental passwords (Spring24 → Summer24).
• Screen against a blocklist of breached, dictionary, and repetitive passwords, and reject matches.

Here is the exact wording from SP 800-63B on composition and rotation:

"Verifiers SHOULD NOT impose other composition rules (e.g., requiring
 mixtures of different character types or prohibiting consecutively
 repeated characters) for memorized secrets."

"Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily
 (e.g., periodically). However, verifiers SHALL force a change if there is
 evidence of compromise of the authenticator."
                              — NIST SP 800-63B, §5.1.1.2

The reasoning is behavioral, not just mathematical. Composition rules and forced rotation both reduce real-world entropy because humans respond to them predictably: they capitalize the first letter, append a 1 and a !, and bump a number each quarter. Attackers know this and bake those exact transformations into their cracking rules. A rule that was supposed to add strength instead narrowed the search space.

Passphrases and Diceware: strong and memorable

A passphrase is several random words strung together. The canonical method is Diceware: you physically roll dice (or use a cryptographic RNG) to pick words from a fixed list. The EFF's large word list has 7,776 words — exactly 6^5, so five dice rolls select one word — and each word contributes log2(7776) ≈ 12.9 bits.

Diceware entropy per word = log2(7776) ≈ 12.9 bits

  4 words ≈ 51.7 bits   (acceptable for low-value accounts)
  5 words ≈ 64.6 bits   (good — recommended minimum for most accounts)
  6 words ≈ 77.5 bits   (strong — high-value accounts, master passwords)
  7 words ≈ 90.5 bits   (excellent — well beyond any offline attack)

The key insight: the words must be chosen randomly, by dice or a cryptographic generator — not by a human writing a memorable sentence. "My dog Rex was born in 2019" feels random but isn't; an attacker's language model assigns it far fewer bits than the count of its characters suggests. Random words win because human memory is good at recalling distinct concrete nouns, while the selection stays uniform across 7,776 possibilities each.

This is why a passphrase beats a "complex" password on both axes at once: more real entropy and easier recall. The famous xkcd #936 comic made this point years before the standards caught up — correcthorsebatterystaple is both stronger and more memorable than Tr0ub4dor&3.

The reuse problem: why a password manager beats any single rule

Even a perfect 80-bit password is worthless if you use it on two sites. Here is the attack, step by step:

1. A breach happens. Site A (often a low-security forum or store) leaks its user database. Breaches are routine — billions of credentials sit in public corpora indexed by services like Have I Been Pwned.
2. Hashes get cracked. If Site A stored passwords badly (fast hash, no salt — see below), attackers recover the plaintext offline.
3. Credential stuffing. Attackers take your email + password pair from Site A and replay it against Site B, Site C, your bank, your email — automatically, millions of attempts per hour. They aren't guessing your password at Site B; they already have it from Site A.

Reuse converts one site's breach into a breach of every account sharing that password. No amount of entropy stops this — the password was never guessed, it was leaked. The only defense is a unique password per site, which is humanly impossible to remember at scale. That is what a password manager is for: it generates and stores a different high-entropy random string for every login, so a breach at one site stays contained to that site.

Generate unique passwords with the password generator — it runs entirely client-side, so the password is created in your browser and never transmitted anywhere — then store each one in a password manager. This single habit beats every other password rule combined.

How sites should store your password

You don't control how a website stores your password, but knowing the standard tells you which sites to trust and why reuse is so dangerous. A correct system never stores the password itself. It stores a salted, slow hash of it.

• Hashing, not encryption. Passwords are hashed (one-way), never encrypted (reversible). A site should be unable to recover your plaintext password even if it wanted to. If a site can email you your original password, it is storing it reversibly — leave. See hashing vs encryption vs encoding for why the distinction matters.
• Salted. A unique random salt per user is mixed in before hashing, so two users with the same password get different hashes — defeating precomputed "rainbow table" attacks.
• Slow, on purpose. General-purpose hashes like SHA-256 are too fast — a GPU computes billions per second. Password storage must use a deliberately slow, memory-hard function so each guess costs the attacker real time and hardware:

Recommended password hashing functions (memory-hard / tunable cost):

  Argon2id   — winner of the 2015 Password Hashing Competition; current best default
  scrypt     — memory-hard; RFC 7914
  bcrypt     — battle-tested since 1999; tunable work factor (cost ≥ 12 today)

  NEVER for passwords:  MD5, SHA-1, plain SHA-256 (fast = crackable in bulk)

This is exactly why the crack-time table above splits into "fast hash" and "slow hash" columns: a site using bcrypt holds attackers near 10^4 guesses/second instead of 10^10 — a six-order-of-magnitude difference that buys even mediocre passwords decades. You can experiment with how different algorithms transform input using the hash generator (note: it computes general-purpose hashes like SHA-256 for learning and integrity checks, not for production password storage — that needs Argon2/bcrypt).

Common mistakes that quietly weaken passwords

Each of these feels secure and isn't. The pattern: they add visible complexity while leaving the password trivially predictable.

• Dictionary words used directly. sunshine, dragon, monkey — all top entries in every breach corpus. Crackers try the full dictionary first, in seconds.
• Leet / character substitution. p@ssw0rd, s3cur3, h4x0r. Substituting a→@, o→0, e→3 is the first transformation every cracking tool applies. It adds essentially zero real entropy.
• Personal information. Names, birthdays, pet names, sports teams, your street. Anything on your social media is in a targeted attacker's wordlist. Buddy2015! is not random — it's your dog and the year you got him.
• Predictable patterns. Capital first letter, number and symbol at the end (Welcome1!), keyboard runs (qwerty, 1q2w3e), or repeated characters (aaaa1111). These are the first rules crackers run because humans use them constantly.
• Reuse. Covered above, and worth repeating: the single most damaging habit. A unique password per site matters more than any complexity rule.
• Appending to an old password on forced rotation. Spring24 → Summer24 → Fall24. If one leaks, the rest are obvious. This is precisely why NIST dropped mandatory rotation.

The fix for all six is the same: stop inventing passwords by hand. Let a generator produce true randomness and a manager remember it, and use a memorable Diceware passphrase only for the handful of secrets you must type yourself (your device login and your password-manager master password).

Putting it together

Three concrete defaults to adopt today:

1. Master password / device login: a 6-word Diceware passphrase (~78 bits). Memorable, typeable, uncrackable offline.
2. Every site login: a 16+ character fully random password from a password generator, unique per site, stored in a password manager.
3. Everywhere it's offered: turn on multi-factor authentication, so a leaked password alone can't log in.

Want to explore the rest of the security toolkit? The tools directory has the password generator, the password strength meter, and the hash generator — all client-side, all free, no accounts.

TL;DR

Strength is entropy, and entropy is length × log2(charset_size) — so each added character multiplies the attacker's work, while a forced symbol barely moves it. A 6-word random Diceware passphrase (~78 bits) is both more memorable and far stronger than P@ssw0rd!, which is a dictionary word with cosmetic edits that crackers reverse instantly. NIST SP 800-63B now agrees: require length, screen against breach blocklists, allow every character including spaces, and stop forcing composition rules and 90-day rotation. But the rule that beats all the others is never reuse a password — one breach plus reuse equals credential stuffing across every account you own. Generate long random passwords with a generator, keep them unique with a manager, and reserve one good passphrase for the master key. Length beats complexity, and uniqueness beats both.