Password Generator

For a password drawn uniformly at random, strength is exactly log2(alphabet^length) bits, which reduces to length × log2(alphabet). Each character from a 62-symbol alphanumeric set contributes 5.954 bits; each character from the full 94-character printable ASCII set contributes 6.555 bits. Between the smallest sensible alphabet and the largest there is barely a bit per character.

Length is the term that scales. Twenty characters of nothing but lowercase letters comes to 94.0 bits. Twelve characters using every printable ASCII symbol comes to 78.7 bits. The symbol-heavy password is shorter, far harder to type, and roughly 15 bits weaker — a factor of about 32,000 in guessing work. Sixteen alphanumeric characters lands at 95.3 bits, comfortably past the point where brute force stops being an attacker's best move.

The same arithmetic explains passphrases. A word drawn from the EFF long wordlist of 7,776 entries carries log2(7776) = 12.93 bits, so six words is 77.6 bits and seven is 90.5. That holds only when the words are selected by dice or a CSPRNG. A phrase you composed yourself is worth a small fraction of it, because you did not sample uniformly and neither will the attacker.

NIST SP 800-63B is unambiguous here. Verifiers shall not impose composition rules such as requiring a mixture of character types, and they shall not require periodic password changes — a forced change is justified only by evidence of compromise. Revision 4 promoted both from recommendations to requirements.

The reasoning is behavioural rather than mathematical. A rule demanding one uppercase, one digit, and one symbol does not sample the space uniformly; it reliably produces a capital in position one, a digit at the end, and an exclamation mark after that. Attackers encode that shape directly into their rule sets, so the mandate narrows the practical search space instead of widening it. Ninety-day rotation fails the same way, turning a password into a counter that increments by one.

What the guidance asks for instead: a minimum of 15 characters where a password is the only authenticator and 8 where it is backed by a second factor, acceptance of at least 64 characters so passphrases are not truncated, acceptance of all printing ASCII including the space plus Unicode, and screening every new password against a blocklist of known-compromised values. A generated password satisfies the length and uniformity requirements by construction. The blocklist check is the part you still have to build.

V8 implements Math.random with xorshift128+, a fast non-cryptographic generator holding 128 bits of internal state. It is a perfectly good statistical PRNG and a useless source of secrets: the state is recoverable from a short run of consecutive outputs, and once recovered, every past and future value is determined. A password generator built on it hands its entire output stream to anyone who can observe a few samples.

crypto.getRandomValues() is the browser-side alternative, backed by the platform CSPRNG. It fills a typed array in place and caps a single call at 65,536 bytes — request one byte more and it throws QuotaExceededError, so anything generating a long batch in one pass has to loop. On the server the equivalents are crypto.randomBytes() and crypto.randomInt().

The distinction reaches well past passwords. Session identifiers, password-reset tokens, CSRF tokens, and API keys all fail in the same way, and they fail silently, because a predictable value is indistinguishable from a random one in a log or a test. The rule of thumb: if a value must be unguessable to someone who has already seen other values from the same generator, it has to come from a CSPRNG.

Having good random bytes is not the same as spending them well. The obvious mapping — take a random byte, index the alphabet with byte % alphabet.length — is only uniform when the alphabet size divides 256 exactly. For a 62-character alphanumeric set, 256 = 4 × 62 + 8, so the first eight characters of the alphabet are produced by five of the 256 byte values while the remaining 54 are produced by four. Those eight are 25% more likely than the rest, in every position.

A single skewed position is not catastrophic, but the bias is systematic and an attacker who knows the alphabet ordering can weight a search accordingly. The fix is rejection sampling: discard any byte at or above the largest multiple of the alphabet size that fits in a byte. For 62 characters that threshold is 248, which throws away 3.1% of draws and leaves the remainder exactly uniform.

Node's crypto.randomInt(min, max) already does this internally, which is the main reason to reach for it rather than hand-rolling the arithmetic. If you are writing the mapping yourself, reject-and-retry is a two-line loop and the modulo shortcut is a two-line bug that no test will catch.

Removing the visually ambiguous characters — capital I, lowercase l, the digit 1, capital O, the digit 0 — takes a 62-character alphabet down to 57. Per character that is 5.833 bits instead of 5.954. Across a 20-character password the total drops from 119.1 bits to 116.7, a loss of 2.4 bits that a single extra character more than repays. If the password will ever be read aloud, retyped from a screenshot, or transcribed off a terminal, make the trade.

Two other constraints are worth checking before committing to a length. Systems that store passwords with bcrypt silently truncate the input at 72 bytes, so anything past that is decorative. And a generator that guarantees "at least one of each type" by writing those characters into fixed positions has made those positions predictable — the guarantee is only safe if the result is shuffled afterwards with the same random source.

A generated password is only useful if it is never reused and never memorised, which in practice means it goes straight into a password manager. To see how a human-chosen password compares against the numbers above, the password strength checker estimates guesses against dictionary and pattern attacks rather than assuming uniform randomness.