Secure Password Generator

Two details separate a correct generator from the many that look correct. The first is the random source. Math.random is a fast pseudo-random generator seeded from the clock, and its output is reproducible by anyone who can narrow down when it ran — which makes any password built from it guessable in a way its length does not suggest. Only crypto.getRandomValues is used here, which draws from the operating system’s cryptographic entropy pool.

The second is modulo bias, and it is subtle enough that most generators have it. Picking a character with randomByte % 87 looks uniform and is not: 256 is not a multiple of 87, so the first 82 characters of the pool come up measurably more often than the last five. Every password inherits a small, real reduction in strength. The fix is rejection sampling — discarding the bytes that land in the uneven tail rather than folding them back in — which costs a handful of extra bytes and makes the distribution actually uniform, which is the only thing that makes the entropy figure honest.

Strength is reported as entropy in bits: log2 of the pool size, times the length. That is the number of guesses an attacker faces, and it is the only measure that means anything. It also shows why the familiar composition rules are largely theatre — a twelve-character password with an uppercase letter, a digit and a symbol carries less entropy than a sixteen-character one made only of lowercase letters. Length dominates everything else.