Password Generator

Length does more than complexity

Entropy is length multiplied by the base-two logarithm of the alphabet size, and the shape of that formula is the whole argument. Adding one character to a password multiplies the search space by the size of the alphabet; adding a whole character class multiplies it once. A 16-character lowercase password carries about 75 bits. A 12-character password using all four classes carries about 79. Adding four more lowercase characters is worth more than adding symbols.

This is why composition rules - one uppercase, one digit, one symbol - have fallen out of favour. They add a couple of bits in theory and, in practice, push people toward the same handful of predictable substitutions: a capital at the front, a digit and an exclamation mark at the end. Attackers model those patterns explicitly, so the rules make passwords more guessable while feeling more secure. NIST's SP 800-63B guidance dropped both composition requirements and mandatory periodic rotation for exactly this reason, and recommends length with a check against known-breached passwords instead.

Entropy measures the process, not the string

This is the distinction most strength meters get wrong. Entropy is a property of how a password was chosen, not of the characters that came out. A generator that picks 12 characters uniformly from a 72-character alphabet produces 74 bits regardless of which 12 it lands on - including the one that happens to spell a word, which is exactly as strong as any other.

The reverse also holds, and matters more. A password a person invented has whatever entropy their choosing process had, which is far less than the formula suggests, because people pick from a tiny corner of the space. A meter looking at the finished string cannot see this: it scores Tr0ub4dor&3 highly while an attacker's wordlist finds it quickly.

The figure shown here is honest because the process is known - uniform random selection, from an unbiased source, over exactly the alphabet you configured. It is not a guess about a string; it is arithmetic about a draw. Which also means it stops being true the moment you edit the result by hand.

Passphrases

Where a password has to be typed on a games controller or read down a phone line, a passphrase of random words is easier to handle at the same strength. The important word is random: chosen from a list, by dice or by a generator, not composed by you.

The standard Diceware list has 7,776 entries, so each word contributes about 12.9 bits. Four words is around 52 bits, which is no longer enough on its own. Six words is about 77 bits and is a reasonable target for something you must memorise, such as the master password on a manager or a disk encryption key. Seven or eight for anything protecting the rest.

A phrase you thought of yourself carries nothing like this. Song lyrics, quotations and grammatical sentences are all heavily represented in cracking dictionaries, and the grammar itself narrows the space enormously.

What actually protects an account

Strength is the part of account security that a generator can help with, and it is not usually the part that fails.

Reuse is. Credentials from a breach are replayed against every other service within hours, so one password shared across sites means the weakest site sets the security of all of them - and no amount of entropy in a reused password helps, since the attacker has the plaintext. Unique per site is the single highest-value habit, and it is only practical with a manager, which is also what defeats phishing pages that a person would not distinguish by eye.

Second-factor authentication is next, ideally a passkey or a hardware key rather than SMS, which is interceptable by SIM swap. And it is worth being clear about the limit of your own effort: if a service stores passwords badly or leaks them in plaintext, nothing you chose makes any difference. That is an argument for unique passwords and 2FA, not for longer ones.

How passwords are actually attacked

Online guessing - typing passwords into a login form - is the attack people imagine and the least effective one, because rate limits and lockouts cap it at a few attempts per account. Everything serious happens offline, after a database of hashes has been stolen, where the attacker's only limit is their hardware.

Offline cracking does not work alphabetically. It starts with wordlists built from previous breaches, hundreds of millions of passwords people actually chose, then applies rules to each: capitalise the first letter, append a year, replace a with @, append an exclamation mark. The transformations people apply to make a password feel stronger are precisely the ones the rules cover.

Credential stuffing is the cheapest attack of all and needs no cracking. Email and password pairs from one breach are replayed against every other service, and the success rate is high enough to be a business, because most people reuse. This is why a unique password per site protects you even when a site you use is badly run.

Managers and passkeys in practice

A password manager is the only realistic way to hold a unique high-entropy password per site, and its second benefit is less discussed: it will not autofill on a domain that merely looks right. A convincing phishing page fools people; it does not fool the manager, because the URL does not match.

Passkeys go further by removing the shared secret. A key pair is generated on the device, the private half never leaves it, and the site stores only the public key - so there is nothing in the site's database worth stealing and nothing to phish, since the signature is bound to the origin. Support is now broad across browsers, operating systems and major services.

Migration is gradual and messy. Most accounts will keep a password as a fallback for years, recovery flows are the weak point in both models, and syncing passkeys between ecosystems is still uneven. Enabling passkeys where offered while keeping strong unique passwords elsewhere is the pragmatic position.

Setting policy for a team or a product

NIST's SP 800-63B is the reference most modern guidance follows, and its recommendations surprised a lot of people: no composition rules, no mandatory periodic expiry, a minimum length of at least eight characters with much longer allowed, and screening against lists of known-breached passwords.

The reasoning is behavioural. Composition rules push everyone toward the same predictable substitutions, and forced rotation produces Password1, Password2, Password3 - each change weaker than the last and written on a note. Expiry still makes sense as a response to a suspected compromise, which is a different thing from a calendar.

Three implementation details matter more than the policy text. Allow long passwords and every character, including spaces and emoji, since a maximum length usually means the password is being stored badly. Do not truncate silently - bcrypt ignores anything past 72 bytes. And check new passwords against a breach corpus, which the Have I Been Pwned range API does without the password leaving the client in a usable form.

Recovery is the part attackers aim at

Every account is only as strong as the weakest way back into it. A twenty-character password means nothing if the reset link goes to an email account protected by a memorable date, which is why the email account underpinning everything else deserves the strongest password and the strongest second factor you are willing to maintain.

Security questions are a password with a public answer. Where they cannot be avoided, treat them as additional passwords: generate a random string for each and store it in the manager.

Backup codes are the part people skip and regret. Generate them when enabling two-factor authentication, print them or store them somewhere that does not depend on the device holding the authenticator, and register a second factor if the service allows one. The failure mode nobody plans for is not an attacker; it is a lost phone and an account whose only second factor was on it.

What the strength meter can and cannot see

The entropy figure shown here is honest because the process is known: uniform random selection from the exact alphabet you configured. It is arithmetic about a draw, not a guess about a string, and it stops being true the moment the result is edited by hand.

Meters that score a password you typed are estimating something much harder. The good ones, like zxcvbn, do it by searching wordlists, keyboard patterns, dates and common substitutions and reporting how quickly those would find it - a far more useful number than counting character classes, which is what naive meters do.

That is why a naive meter rates P@ssw0rd1 highly and a wordlist finds it in milliseconds. If you are building a signup form, a pattern-aware meter plus a breach check gives users feedback that corresponds to real risk; a coloured bar driven by length and symbols mostly teaches them to add an exclamation mark.