Password Generator

The characters are drawn with `crypto.getRandomValues`, the browser’s cryptographic random number generator, which is seeded from the operating system’s entropy pool. The alternative, `Math.random`, is present in every browser and disqualified here: its algorithm is public, its internal state is small, and recovering that state from a short run of outputs is a solved problem with published code. A generator built on it produces passwords whose real keyspace is the size of the generator’s state no matter how long the password looks.

You cannot tell the two apart by looking. That is exactly why it is worth saying which one is being used, and why there is a test in this project that fails if `Math.random` ever appears in this file.

Turning a random byte into a random character is usually written as `byte % alphabet.length`, and that is subtly wrong whenever 256 does not divide evenly by the alphabet size. With twenty-six letters, the bytes 0 to 255 cover `a` through `v` ten times each and `w` through `z` only nine — so the first twenty-two letters come up about 11% more often than the last four.

It is a small flaw and it is a real one, and it is the single most common defect in generators of this kind. The fix is to throw away the values in that short tail and draw again, which costs one loop and less than two draws per character on average. That is what happens here.

Entropy is stated in bits, and it is the honest way to describe a password’s strength: each bit doubles the number of guesses needed. A twenty-character password from all four sets is about 130 bits, which means roughly 2^130 possibilities — a number with no physical meaning, which is the point.

It also makes the trade-offs visible. Dropping symbols from a twenty-character password costs about 11 bits. Removing look-alike characters costs about 3. Adding four characters gains about 26. This is why length beats complexity every time: the four extra characters are worth more than every symbol on the keyboard, and they are easier to accept for a password you are never going to type by hand.

If you tick digits, the password contains a digit. This is not automatic — drawing twenty characters at random from a mixed alphabet leaves a real chance of getting none from one of the sets, and the result is a password a policy rejects and you have to generate again.

The characters that guarantee it are placed first and then the whole thing is shuffled, because otherwise every password would begin with a lower-case letter, then an upper-case one, then a digit, then a symbol — a pattern that removes the first few characters from anybody’s guessing problem. The guarantee costs a fraction of a bit of entropy, well below the rounding in the figure shown.

Quotes and backslashes are left out on purpose. They are the characters that break a shell command, a CSV export, a connection string or a config file, and a password that cannot be pasted where it is needed is a password somebody replaces with a weaker one they can.

Everything else in the printable ASCII range is there. If a system rejects the result, it is almost always because it has an undisclosed maximum length or a symbol blocklist — both signs that it is storing passwords in a way it should not be, and a good reason to make sure that password is used nowhere else.

A strong password you reuse is a weak password, because its strength stops mattering the moment any site that has it is breached. The value of generating them is that every account gets a different one, and that only works if something remembers them for you.

So use a password manager — any of them, including the one already built into your browser. The generator here is for the moment you are standing in front of a form; what makes it worth anything is that the result goes somewhere you will find it again.