How to Generate Strong Passwords (and Why Length Wins)

Most advice about passwords is folklore dressed up as rules. This is the part the rules are trying to approximate, written for people who can do a little arithmetic and would rather understand the thing than memorize a checklist.

What "strong" actually means

A password is strong when an attacker who is guessing cannot get through it in a reasonable amount of time. That's the whole goal. Everything else (special characters, mixed case, the little strength meter turning green) is a proxy for one number: how many guesses an attacker would have to make on average.

That number is measured in bits of entropy. Each bit doubles the number of possibilities. A secret with

bits of entropy takes up to guesses to brute-force, and on average half that. The practical takeaway:

• ~40 bits: trivially crackable offline. Fine for a throwaway forum, nothing real.
• ~60 bits: resists casual offline cracking, marginal against a serious adversary.
• ~80 bits: comfortable for most accounts.
• ~100+ bits: overkill for almost everything, and that's a good place to be for a password manager's master password.

The key word is offline. If an attacker steals a password database and cracks it on their own hardware, they can attempt billions of guesses per second. Online guessing against a live login is far slower (rate limits, lockouts), but you should design for the worst case, because breaches happen and you don't control how the other side stored your hash.

The entropy formula, and the trap inside it

For a password drawn randomly from an alphabet of size

, with length , the entropy is:

textCopy
entropy_bits = L * log2(R)

So for the common character classes:

• digits only (R = 10): ~3.32 bits per character
• lowercase letters (R = 26): ~4.70 bits per character
• lower + upper + digits + symbols (R ≈ 95): ~6.57 bits per character

A 12-character password from the full 95-character keyboard set gives

bits. Solid.

Here's the trap: that formula is only valid if every character is chosen uniformly at random.

has twelve characters from the full set, so the formula says ~79 bits — but it has almost none, because no attacker guesses character by character. They guess patterns: dictionary words, the leetspeak substitutions everyone makes, a capital at the front, a number and a symbol at the end. Real cracking tools encode these patterns directly. Your clever substitution is in their default ruleset.

This is why a human-chosen password and a generated one of the same length are not remotely equivalent. The math only applies to true randomness.

Why length beats complexity

Look at the formula again. Length

is a multiplier; alphabet size is buried inside a logarithm. Logarithms grow slowly. That asymmetry is the whole argument.

Compare two passwords with roughly equal entropy:

textCopy
lowercase only, length 17:   17 * 4.70 ≈ 80 bits
full symbol set, length 12:  12 * 6.57 ≈ 79 bits

They're equally strong, but the lowercase one is far easier to type and read. Adding symbols buys you about 1.9 bits per character over lowercase. Adding characters buys you the full per-character entropy of whatever alphabet you're using. Length is simply the more efficient lever.

This is also why the old corporate rule — "8 characters, one uppercase, one number, one symbol" — aged so badly. It forces complexity (which humans satisfy in predictable ways) while permitting short length (which caps your maximum possible entropy). NIST's own guidance reversed course years ago: drop the mandatory-composition rules and the periodic forced resets, and let people use long passphrases instead. Length is the thing that scales.

If you only remember one sentence: a longer random password is stronger than a shorter complicated one, and easier to live with.

Passphrases: randomness you can actually remember

There is one secret you can't outsource to a manager — the master password that unlocks the manager itself. For that, you need something strong and memorizable. Passphrases solve this.

The method (often called diceware) is to pick several words at random from a known wordlist. The entropy is exact and honest:

textCopy
entropy_bits = number_of_words * log2(wordlist_size)

A standard diceware list has 7,776 words, so each word contributes

bits. Therefore:

textCopy
4 words ≈ 51.7 bits   (weak-ish, fine for low stakes)
5 words ≈ 64.6 bits   (good)
6 words ≈ 77.5 bits   (strong — recommended for a master password)
7 words ≈ 90.4 bits   (very strong)

A six-word passphrase like

has ~77 bits, beating most 12-character symbol soup, and you can actually hold it in your head after a few days of typing it.

Two conditions make the math true, and both matter:

1. The words must be chosen randomly, not picked by you. "correct horse battery staple" the concept is sound; you choosing four words you like is not — that reintroduces human predictability.
2. The number of words is your security, not the punctuation between them. Hyphens, spaces, capitalization on a word or two — fine, but don't count them as meaningful entropy. They add maybe a bit or two and exist for site requirements, not strength.

Use a password manager, and stop reusing passwords

The single highest-impact security habit is not making each password stronger — it's making each one unique. Reuse is what turns one company's breach into a key to your entire life. Attackers take leaked email/password pairs and replay them across hundreds of sites automatically; this is called credential stuffing, and it works precisely because people reuse.

You cannot remember a hundred unique high-entropy passwords. You're not supposed to. A password manager exists so you remember exactly two things:

• one strong passphrase (the master password — make this a 6+ word diceware phrase)
• where your recovery codes are kept offline

Everything else becomes a long random string the manager generates, stores, and autofills. You never see most of your passwords, never type them, and never reuse one. The threat model shifts cleanly: instead of defending a hundred accounts, you defend one vault. Pair it with a second factor on the accounts that matter (a hardware key or an authenticator app, not SMS where you can avoid it) and you've closed the most common attack paths.

A reasonable per-account password from a manager is 16–20 random characters. There's no real benefit pushing individual site passwords to absurd lengths — past ~80 bits the password is no longer the weak point; phishing, malware, and bad server-side storage are. Spend your effort there.

How a good generator actually works

A password generator's only job is to produce unpredictable output. That word is doing heavy lifting, because there are two completely different kinds of "random" in software, and only one is safe here.

Most languages' default random functions —

in JavaScript, the module in Python — are pseudo-random number generators (PRNGs). They're fast and statistically uniform, which is great for shuffling a game deck or sampling data. But they're deterministic: seeded from a small internal state, and designed to be reproducible. An attacker who observes a few outputs can sometimes reconstruct the state and predict the rest. For passwords, that's disqualifying.

What you want is a cryptographically secure pseudo-random number generator (CSPRNG). It's seeded from the operating system's entropy pool (hardware noise, interrupt timing, and similar physical sources) and built so that observing past output gives you no usable advantage in predicting future output. In the browser this is

; in Node it's ; in Python it's the module.

There's a second, subtler pitfall even when you start from a CSPRNG: modulo bias. The naive way to pick a character is to grab a random byte and take it modulo the alphabet size. If the alphabet doesn't divide 256 evenly, the lower-indexed characters come up slightly more often, leaking a sliver of entropy. The correct fix is rejection sampling — discard and redraw any byte that falls outside the largest clean multiple of the alphabet size:

javascriptCopy
function pick(alphabet) {
  const R = alphabet.length;
  const max = Math.floor(256 / R) * R; // largest clean multiple
  const buf = new Uint8Array(1);
  let b;
  do {
    crypto.getRandomValues(buf);
    b = buf[0];
  } while (b >= max); // reject biased range, redraw
  return alphabet[b % R];
}

That's the entire core of a trustworthy generator: a CSPRNG as the source, and unbiased uniform selection from a defined alphabet. Everything else — toggles for symbols, length sliders, "avoid ambiguous characters like

///" — is convenience layered on top. (Note that excluding ambiguous characters shrinks the alphabet, so add a character or two of length to compensate if you turn it on.)

This is exactly how the Cosmovex password generator is built: it runs entirely in your browser using the platform CSPRNG, draws characters without modulo bias, and never transmits the result anywhere — the password is generated on your device and stays there. A generator that sends candidate passwords to a server, or that you can't verify runs locally, defeats its own purpose. If you want to confirm any web tool's behavior, open the network tab while you generate; a correct one makes no requests.

A short, honest checklist

• Let a tool generate random passwords; don't invent them yourself. Human-chosen passwords overstate their entropy.
• Favor length. 16+ random characters per site, or a 6-word passphrase for anything you must memorize.
• Make every password unique. Reuse is the failure mode that actually gets people compromised.
• Use a password manager so uniqueness costs you nothing.
• Turn on a second factor where it matters; prefer hardware keys or authenticator apps.
• Insist that your generator is CSPRNG-backed and runs locally. You can generate one right now without anything leaving your machine.

The arithmetic isn't complicated, and it points consistently in one direction: real randomness, generous length, and one strong secret guarding the rest. Get those three right and the rest of the advice mostly takes care of itself.