What makes a password strong: length, entropy, policies and generators

Password advice has been wrong for so long that most people are still following rules written for a threat model that no longer exists. Mixed case, a number and a symbol; change it every ninety days; never write it down. Each of those made a kind of sense in 1998 and each is now either useless or actively harmful. What actually determines whether a password survives is a single measurable quantity — how many equally likely possibilities it was drawn from — and almost everything else follows from that number. This guide covers what entropy means in practice, how passwords are really cracked, why length beats complexity, where passphrases fit, what makes a machine password different from a human one, and how to use the password generator here, which shows the entropy of what it just produced.

Entropy, in numbers you can act on

Entropy is measured in bits, and each additional bit doubles the number of guesses required. It depends on how a password was generated, not on how it looks: a random 16-character string and a memorable sentence of the same length are not remotely equivalent, because the second was drawn from a far smaller set of plausible options.

Here is what those bits buy, assuming an attacker with a stolen database and serious hardware making a trillion guesses per second against a fast hash:

Two caveats make this table optimistic in one direction and pessimistic in the other. It assumes a fast hash — if the site stored your password with bcrypt, scrypt or Argon2id, the same hardware manages perhaps a hundred thousand guesses a second instead of a trillion, and every row moves seven or eight orders of magnitude in your favour. But you have no idea which hash a given site used, so assume the worst. And it assumes the attacker is guessing randomly, which they are not — which is the next section.

How passwords are actually cracked

Nobody starts at “aaaaaaaa” and counts. Real attacks work in this order:

1. Credential stuffing. Take username and password pairs from previous breaches — there are billions in circulation — and try them everywhere else. This costs nothing and succeeds constantly, because password reuse is near-universal. No cracking is involved at all.
2. Wordlists. Every password ever leaked, ordered by frequency. If your password has appeared in any breach, it is in the first few million guesses.
3. Wordlists plus mangling rules. Capitalise the first letter, append 1, append the current year, swap a for @ and o for 0, add an exclamation mark. These transformations are built into every cracking tool. P@ssw0rd! is not meaningfully harder than password.
4. Targeted guessing.Your employer, your city, your children’s names, your team, your dog — all public, all cheap to combine.
5. Brute force, only when everything above has failed, and only against short passwords. Against a genuinely random 16-character password, it never finishes.

The lesson is that uniqueness matters as much as strength. A superb password reused on a site that stored it badly is a compromised password everywhere you used it.

Length beats complexity

Adding one character multiplies the search space by the size of the alphabet; adding a symbol type merely enlarges the alphabet a little. Compare an eight-character password using every symbol on the keyboard with a sixteen-character one using only letters and digits: the first has around 51 bits, the second around 95. Length wins overwhelmingly, and it is easier to type and easier to remember.

This is why the current guidance from NIST — the standards body whose earlier advice created the complexity-rule era — now says the opposite of what most login forms still enforce: no mandatory composition rules, no forced periodic expiry, a minimum length of at least eight and support for at least 64, all printable characters including spaces allowed, paste permitted, and every new password checked against a list of known-breached ones. Composition rules make passwords predictable in exactly the way cracking rules exploit.

Passphrases: strength you can actually say out loud

When a password has to be typed from memory — a laptop login, a password manager’s master password — random characters are a poor fit for human beings. A passphrase of randomly chosen words gives comparable entropy in a form you can remember and read over a phone.

The word randomly is doing the work. Words you choose yourself are not random; words picked by a computer from a known list are, and the entropy is exactly calculable. The passphrase mode of the generator here uses the EFF short wordlist — 1,296 short, unambiguous, easy-to-type words — which contributes about 10.3 bits per word, and appends a two-digit number. That gives:

• 4 words — 48 bits. Fine for low-stakes accounts.
• 5 words — 58 bits. The default; reasonable for most things.
• 6 words — 69 bits.
• 7 words — 79 bits. Appropriate for a password manager’s master password or a disk encryption key.

A useful side effect: the words are capitalised, hyphen-separated and end in digits, so a generated passphrase satisfies the upper/lower/digit/symbol rules that badly designed forms still demand, without being weakened by them.

Machine passwords are a different problem

A database user, a service account, an API integration — these are never typed from memory, live in a secret manager or an environment variable, and fail in ways human passwords do not. The generator here is built around that case, with per-engine presets for MySQL, MariaDB, PostgreSQL, SQL Server, Oracle, MongoDB, Redis and Elasticsearch, and it defaults to 16 characters (32 for Redis, 20 for Elasticsearch, which is where those engines’ conventions sit).

Three failure modes it exists to prevent:

• Connection strings. A password containing @, :, /, ?, #, [ or ] breaks a URI, because those characters delimit its parts. The default “connection-string / shell safe” charset uses only - . _ ~ + = as symbols, which is safe inside a URI, inside shell quoting and inside a YAML value. It costs a little entropy — 97 bits at 16 characters instead of 102 — and saves an afternoon.
• Shells and config files. A password with $ in it gets variable-expanded by a shell; one with a quote in it breaks the file it sits in. Same solution.
• Engine policies.Each preset encodes that engine’s well-known default rules, and a checker box validates any password you paste against them — including “must not contain the username”, which is why there is a username field beside it. Useful when the password was chosen elsewhere and the server keeps rejecting it without saying why.

Two convenience buttons follow from the same thinking: Copy URI-encoded gives you a percent-encoded form for a connection URI when you do need the full symbol set, and Copy export produces the shell line with the environment variable that engine’s command-line tools actually read — MYSQL_PWD, PGPASSWORD, REDISCLI_AUTH and so on — so the password stays out of your shell history.

Where a generator fits alongside a manager

For your own accounts, a password manager should be generating and storing everything; you should not know most of your passwords. A standalone generator is for the credentials a manager does not naturally hold: a database user you are creating in a migration, a service account, a root credential going into a secret manager, a shared credential you need to hand to someone in a specific format. That is why this one has engine presets, a policy checker and an entropy readout rather than a browser extension.

The generation itself uses the browser’s cryptographic random source, drawn with rejection sampling so that no character is even slightly more likely than another, and guarantees at least one character from each required class. Nothing is transmitted: a password that reaches a server before it reaches you is not a password you generated, it is a password someone else also has. That is the reason a generator belongs in the page.

If you need to confirm that the password which landed in a config file is the one you generated — after a copy, a paste, and a shell that may have eaten a character — hash both and compare. The hash generator makes that a five-second check, and the hashing guide explains why a password should never be stored that way.

The rules that actually matter

1. Unique per site, without exception. This defeats credential stuffing, which is the most common attack by an enormous margin.
2. Use a password manager. It is the only way rule one is achievable. Give it a long passphrase as its master password.
3. Turn on a second factor, preferring passkeys or a hardware key over app codes, and app codes over SMS.
4. Length over symbols. 16 random characters, or 5–7 random words.
5. Change on suspicion, not on schedule.
6. Protect the recovery path. An account recoverable through an email address with a weak password is only as strong as that address.