Password Entropy and Strong Credentials

What entropy actually measures

Entropy counts guesses an attacker must try on average — expressed in bits. Each character drawn uniformly from a set of N possibilities adds log2(N) bits. A lowercase letter adds about 4.7 bits; the full printable ASCII set about 6.5. The numbers that matter: 80 bits is the practical minimum for important accounts, 100+ is comfortable, and every additional bit doubles the attacker's work. This is arithmetic, not intuition — and it is why length dominates.

Length beats cleverness, decisively

The search space grows exponentially with length but only linearly with alphabet size. Four extra characters from a 94-character set add roughly 26 bits; adding ten symbol types to a short password adds maybe seven. This is why 'correct horse battery staple' style passphrases work: four random words from a 7,776-word list carry over 51 bits while remaining typable. Attackers know the common substitutions — P@ssw0rd adds almost nothing.

Randomness is the part humans cannot do

Human-chosen passwords follow patterns: capital first, digits last, predictable substitutions. Attackers run dictionaries and pattern rules first because they work — the rockyou list, fifteen years old, still cracks a share of real passwords. A generator's entire value is producing strings with no pattern to exploit. The moment a generated password gets 'tweaked to something memorable', the tweak reintroduces exactly the predictability the randomness removed.

Generator settings decoded

Length: the strongest lever — set as high as the service allows, typically 16 to 24. Character sets: include all classes unless a service forbids specific characters; exclusions cost a few bits but rarely break things. Avoid ambiguous characters (I, l, 1, O, 0) only when typing manually into devices without paste support. Require-each-class options exist for legacy password policies that demand them — they slightly reduce entropy but satisfy the policy.

Passphrases: when you must type it

For the few passwords entered from memory — your password manager's master, disk encryption — random-word passphrases win: high entropy with human-typable input. The words must be chosen randomly by the generator, not by you; 'my favorite three words' is a dictionary attack target. Five words from a large wordlist reaches roughly 64 bits; six clears 77 — enough for master-password duty when paired with slow hashing.

The reuse problem generation solves

Breaches prove that any service's database can leak, so the same password across sites means one breach becomes all breaches. Unique passwords per account are not feasible from memory — which is the actual argument for generating per-site and storing in a manager. Generation plus a manager converts password security from a memory problem into a storage problem, where tooling can help.

Storage: what must follow generation

A generated password pasted nowhere is lost; stored in a note app it is one compromise away. Password managers encrypt the vault with your master password and unlock via device biometrics. The manager's vault is the one place where password strength concentrates — make it a long passphrase, enable its two-factor, and let it autofill everything else. Generation is only step one of a two-step practice.

Why generate in the browser, locally

Passwords are the one string where processing location is existential: a server-side generator sees every password it creates. Local generation runs the random selection in your browser and the string moves only to your clipboard or manager. Check that no network request carries your generated value — for this tool, none exists. The same principle argues for open-source managers: their code is auditable.

When a password is not the answer

Generation does not fix authentication design. Passkeys eliminate the shared secret entirely and beat even strong passwords against phishing. Two-factor codes contain breach damage. For services you control, prefer offering passkeys and TOTP over ever-longer passwords; for services you consume, enable both where offered and let the generator handle whatever password remains.

Adapting to arbitrary site policies

Legacy password rules — maximum lengths, required character classes, forbidden symbols — constrain what you can generate, and the generator settings map directly onto them. The mapping discipline: set length to the policy maximum (not the default), enable only the required classes, exclude the forbidden characters. Two policies deserve pushback when possible: maximums under sixteen characters and requirements to rotate periodically, both of which security guidance has moved away from. Where you cannot change the policy, generate to it exactly — a compliant random password still beats a hand-crafted one within the same rules.

Rotation: when changing passwords actually helps

Scheduled rotation of unbreached passwords mostly produces weaker choices and written-down passwords — modern guidance reserves rotation for cause. The trigger list: a breach affecting the service, credential-stuffing alerts, suspicion of phishing success, or shared credentials after someone's access ends. Each trigger is a generate-and-store event: new random password, saved to the manager, old one invalidated. The practice that ties it together: unique passwords everywhere mean a breach at one service never forces rotation at others — containment is built in by generation, not by vigilance.

What actually makes a generated password strong

Password strength is arithmetic, not aesthetics: every character chosen from a larger alphabet multiplies the guessing space, and length does the same exponentially. A 16-character password over lowercase, uppercase, digits, and symbols has roughly 95^16 possibilities — beyond any brute-force budget — while an 8-character one from the same set is within reach of serious attackers in days. This is why the length control matters more than any checkbox: moving from 12 to 16 characters buys more security than adding every symbol class to a short password.

Randomness quality is the other half and the invisible half. A password is only as strong as the generator behind it; the difference between cryptographically secure randomness and a predictable algorithm is the difference between an unguessable string and one an attacker can reconstruct. Browser-based generators built on the platform's secure random source are sound; anything that derives passwords from patterns, birthdays, or word substitutions is a dictionary attack waiting to happen.

The operational rules follow from the math. Use a unique generated password per account — reuse turns one breach into many. Prefer a password manager to store them, because humans cannot hold dozens of 16-character strings and writing them in a text file defeats the exercise. And where a service offers it, turn on a second factor: a strong password plus 2FA means an attacker needs both the secret and the device.

Common mistakes with this tool

• Editing generated passwords into 'memorable' patterns.
• Reusing one strong password across multiple services.
• Choosing passphrase words yourself instead of letting randomness choose.
• Generating passwords on sites that transmit them to a server.

Frequently asked questions