Elofyn

//Tools  ·  /tools/password/about

← Back to the tool

About password generators.

Why password generators exist, how to read an entropy figure, and the trade-offs between length, character classes, and human-memorable passphrases — written for engineers and sysadmins who want a defensible answer, not just a stronger string.

1. The problem with human-picked passwords

Humans are terrible random sources. Year after year, leaked credential dumps tell the same story: the top entries are 123456, password, qwerty, a sports team, a date of birth, or a transparent l33t substitution of the same. Even cautious users — the ones who pick a phrase from a favourite book and capitalise the first letter — radically undercount what a modern adversary can do with a leaked password-hash file, a single GPU, and a dictionary attack that already knows every transformation a human is likely to apply. A password generator removes the picker from the entropy calculation. It draws from a uniform distribution over a defined character pool, and what comes out has no semantic shape an attacker can exploit.

2. What this tool does

The Password Generator uses your browser’s OS-backed cryptographically-secure random number generator (window.crypto.getRandomValues) to draw uniformly from an assembled character pool — some combination of lowercase, uppercase, digits, and a fixed 28-character symbol set, optionally with look-alike characters (0 O I l 1) excluded. It computes the entropy in bits as H = L · log2(N) where L is the chosen length and N is the pool size after any look-alike removal. It also scores the generated string with zxcvbn — a pattern-aware estimator — so the strength label reflects what an attacker who knows about dictionaries, keyboard walks, and l33t substitutions would actually see. Nothing leaves your browser.

3. A brief history of password generation

The password as a concept is older than the field that studies it. MIT’s Compatible Time-Sharing System (CTSS) and its successor Multics introduced the per-user password file in the 1960s, and the now-canonical Password Security: A Case History by Robert Morris and Ken Thompson (1979) gave the field its first rigorous treatment — including the original motivation for password hashing and the per-user salt. By the early 1990s, Unix admins were generating credentials with command-line utilities: Theodore Ts’o’s pwgen shipped in 1995 with pronounceable-output mode as its headline feature, and APG (Automated Password Generator) followed in 1999 with FIPS-181-pronounceable support.

The 2010s brought generators inside password managers: KeePass had one from the start, 1Password and LastPass normalised the “Suggest Password” pattern at the browser-extension layer, and from 2018 (Safari) and 2019 (Chrome) the browsers themselves started offering a generated password whenever an input was identified as a new credential. In parallel, the field made a deliberate turn toward human-memorable high-entropy strings: Arnold Reinhold’s Diceware (1995) and the EFF’s 7776-word Diceware list (2016) pushed many practitioners toward passphrases — four to six random words drawn from a curated list — for credentials the user must commit to memory. This tool deliberately scopes itself to random characters: passphrase generation is a separate concern with different trade-offs, slated for a future /tools/passphrase.

4. Technical principles

Entropy is the right measure. When a password is drawn uniformly from a pool of N characters and is L characters long, its Shannon entropy is H = L · log2(N). A worked example: 20 characters drawn from the full 94- character printable-ASCII pool (lowercase, uppercase, digits, symbols) yields 20 · log2(94) ≈ 131 bits. Why bits and not a complexity score: bits compose linearly with length, so the trade-off between adding a character and enabling another character class is legible. Adding one character to a 94-character pool is worth about 6.55 bits; flipping symbols off (dropping pool size from 94 to 62) costs about 6.0 bits across a 20-character password. The numbers come out roughly equal — length and class cardinality are nearly interchangeable currencies.

CSPRNG vs PRNG. JavaScript’s Math.random() is a deterministic pseudo-random number generator: implementations vary by engine, but all are seedable, all have visible internal state, and all are predictable across calls given a few outputs. That is fine for animation jitter and unit-test shuffles, and actively dangerous for security. The right primitive is a cryptographically-secure pseudo-random number generator (CSPRNG) — one whose output is computationally indistinguishable from true random to a bounded adversary. The Web Crypto API exposes such a CSPRNG via window.crypto.getRandomValues, which delegates to the operating system’s entropy-seeded generator (/dev/urandom on Linux, BCryptGenRandom on Windows, SecRandomCopyBytes on macOS). NIST’s digital identity guidelines (SP 800-63B) require an approved random-bit generator for any memorized-secret generation; this tool meets that requirement by using the platform CSPRNG directly, with rejection sampling to remove the modulo bias that arises when drawing a uniform integer from a power-of-two source over a non-power-of-two pool.

Why an estimator, not just charset math. The naive bit calculation above assumes every character is independently uniform. That is true for thisgenerator’s output, but it is false for human-chosen passwords — and many of the passwords your users will eventually pick on their own. zxcvbn, introduced by Daniel Lowe Wheeler in his USENIX Security 2016 paper “zxcvbn: Low-Budget Password Strength Estimation”, recognises dictionary words (English, names, the top 30 000 leaked passwords), keyboard walks (qwerty, asdfghjkl), repeats, sequences, dates, and l33t substitutions, and estimates the time an attacker would need to crack the password under several attack models. For a generator output that is genuinely uniform, the zxcvbn score will almost always match the bit math; for an input the user might also be reusing somewhere, it gives a much more honest signal.

Targets.A common rule of thumb: 80 bits of entropy is a reasonable floor for resistance to online attacks (where rate-limits and account lockouts cap the attacker’s guess rate at thousands per second), and 128 bits is the standard threshold for resisting offline attacks on a leaked hash dump by a well-funded adversary with modern GPU clusters. SP 800-63B Appendix A discusses this curve in detail and explicitly avoids prescribing a single number; the message is that length is the cheapest way to buy more bits and that complexity rules (“must contain a digit and a symbol”) generally cost more than they earn.

5. How to choose options

Length over complexity. Within reason, a 20-character lowercase-only password (about 94 bits) is stronger than a 10-character mixed-class password (about 66 bits). If a site accepts long passwords, length is the cheapest entropy you can buy. Push as long as the site tolerates and as long as you can paste comfortably.

When to enable symbols.Only when a site imposes a complexity policy (PCI-DSS, SOC2, internal compliance) or genuinely allows them across every endpoint you’ll use. Otherwise symbols cost typing on mobile keyboards, get mangled by shells, and earn fewer bits than an extra two characters of length on a smaller pool would.

When to disable look-alikes. If you will have to re-type the password from a screen — a terminal session, a printed slip, a hand-off dictated over the phone — flip the look-alikes toggle off so 0 O I l 1 don’t become a source of typing errors. The cost is a few bits of entropy; compensate with 2-3 extra characters of length and you’re ahead.

When not to use this tool. If the password is one the user must memorise unaided, generate a passphrase instead — random words drawn from a curated wordlist such as Diceware or the EFF list. A six-word EFF passphrase carries about 77 bits of entropy and is far easier to recall than a 13-character random string with the same bit count. Passphrase generation is out of scope for this tool; a sibling /tools/passphrase may ship later.

6. Common use cases

Spinning up a new service account or machine identity. Rotating an API token or DB credential during an incident. Drafting a one-time recovery code that you will store in a separate vault. Seeding a password-manager entry when the site’s “suggest password” flow is broken or unavailable. Generating a master key for a fresh vault — with the strong caveat that vault master keys should generally be longer than the default and, when memorisation is required, paired with a passphrase fallback.

7. Anti-patterns

Reusing across sites. A leak on one site becomes a credential-stuffing attack on every other. Sending the password by chat or email. Both have indefinite retention, syncing to attacker- accessible backups, and casual sharing — use a one-time secret service or an out-of-band channel. Storing in plaintext on disk. creds.txt on your desktop will leak when your laptop does. Use a password manager. Layering a memorable pattern on top of a generator. Taking the generator’s output and rewriting the first and last characters “so I can remember it” re-introduces the human picker the generator is supposed to remove. Trusting a JavaScript generator that uses Math.random. The output is predictable from a few samples; the tool you are using right now uses crypto.getRandomValues and would fail closed (showing a muted notice) on a browser that lacks it, rather than silently falling back.

8. References

  1. National Institute of Standards and Technology. Digital Identity Guidelines: Authentication and Lifecycle Management. NIST Special Publication 800-63B. pages.nist.gov/800-63-3/sp800-63b.html
  2. Wheeler, D. L. (2016). zxcvbn: Low-Budget Password Strength Estimation. Proceedings of the 25th USENIX Security Symposium. usenix.org/conference/usenixsecurity16/.../wheeler

Related tools

  • Hash Generator — SHA-256 / SHA-512 / BLAKE2. Same “cryptographic primitive in your browser” lane — devs who generate a password often need to hash one too (compare-against-leaked-hash workflows, password- equality checks for tests).
  • UUID Generator — RFC 4122 v4 / v7. The other “I need a random string for a fresh resource” tool — service accounts often get a UUID and a password together.
  • Base64 / URL / HTML Encoder–Decoder — adjacent for token workflows. Generated passwords frequently get base64-wrapped before paste (basic auth headers, env-file encoding).
  • JWT Decoder — inspect JWTs locally. Same security-tool family; pairs cleanly with passwords on the auth surface.
  • Slug Generator — URL-safe identifiers. Fills the “I need a deterministic identifier alongside a random secret” slot (e.g. naming a service account acme-prod-2026 with a fresh password).