Generate a strong password

What this does

It draws a password one character at a time from the browser’s cryptographic random number generator, and then tells you how much randomness is actually in it. The second half is the part most generators get wrong, and it is the only part worth trusting.

A password’s strength is not a property of the string. It is a property of the process that produced it: how many equally likely passwords could have come out instead. Tr0ub4dor&3 looks strong and is not, because the process that produced it was a person substituting digits for letters in a dictionary word. Twenty characters drawn uniformly at random are strong even if one of them happens to spell something, because an attacker has no way to know that they did.

The method

Every byte comes from crypto.getRandomValues, defined in the Web Cryptography specification and backed by the operating system’s cryptographic generator. Math.random is not used anywhere, and there is a test that fails if it ever is. Math.random is a fast, non-cryptographic algorithm whose entire internal state can be recovered from a few of its own outputs, which means one password from it can be enough to predict the next.

Turning a random byte into a random character is where the second mistake usually happens. A byte is 0 to 255 and the alphabet here is 90 characters, and 256 is not a multiple of 90, so taking the remainder directly would return the first 76 characters of the alphabet three times per 256 bytes and the remaining 14 only twice - a 50% bias towards the front of the alphabet. Instead, any byte at or above 180, the largest whole multiple of 90, is thrown away and another is drawn. The cost is well under one extra byte per character; the benefit is that every character is exactly as likely as every other.

“At least one of every kind” is handled by rejection, not by repair. The common shortcut is to place one character of each required class at a fixed position and shuffle the rest, which produces a distribution that is not uniform and whose entropy nobody can state. This tool draws a whole candidate, checks it, and if a class is missing throws the candidate away and draws another. That samples the set of valid passwords uniformly, which means the entropy of the result is exactly the base-2 logarithm of how many valid passwords exist.

Counting them is inclusion and exclusion over the classes:

valid = SUM over subsets S of the classes of (-1)^|S| x (A - size(S))^L

  A = alphabet size, L = length, size(S) = characters in the classes in S

bits = log2(valid)
     = L x log2(A) + log2( SUM (-1)^|S| ((A - size(S)) / A)^L )

The second line is the one the code runs. Computed directly, the first is a difference between numbers around ten to the two hundred and fiftieth, which no floating-point number can hold; dividing through by A^L first makes every term a ratio between zero and one, and the sum stays accurate at any length.

Before you read on

Twenty characters drawn from a 90-character alphabet is 129.8371 bits. Then you tick at least one of every kind. What does that requirement cost?

• ANothing — a rule about content cannot reduce randomness.

  It can and does: it rules out every string missing a class, so there are fewer valid passwords to be one of.

• B0.148 bits.

  Yes — 129.6891 against 129.8371. Barely measurable.

• CSeveral bits — four fixed positions is four characters wasted.

  That is the cost of the shortcut implementation, not of the rule. This tool does not use it.

0.148 bits, taking 129.8371 down to 129.6891. It is that small because 90.25% of twenty-character strings already contain all four kinds by chance, so the rule discards under a tenth of the possibilities. Put it next to what a single extra character buys — 6.49 bits, forty times as much — and the complexity policy your bank insists on turns out to be a rounding error, while the length limit it also imposes is the thing actually costing you. The tool gets that figure honestly by drawing whole candidates and discarding invalid ones, so the result is a uniform sample of the valid set and its entropy is exactly log2 of how many valid passwords exist.

1. byte = 0 to 255,  alphabet = 90

   Every byte comes from crypto.getRandomValues. Math.random is not used anywhere, and a test fails if it ever is.

2. character = byte % 90     <- wrong

   256 is not a multiple of 90, so this returns the first 76 characters three times per 256 bytes and the other 14 only twice. A 50% bias towards the front of the alphabet.

3. if (byte >= 180) draw another

   180 is the largest whole multiple of 90 below 256. Throwing the remainder away is what makes the rest uniform.

4. character = byte % 90

   Now every character is exactly as likely as every other. The cost is well under one extra byte per character.

A worked example

Twenty characters, all four kinds switched on, look-alikes allowed, at least one of every kind required.

Alphabet	26 + 26 + 10 + 28 = 90
Unconstrained entropy	20 x log2(90) = 129.8371 bits
Share of strings holding all four kinds	90.25%
Entropy as generated	129.6891 bits, shown as 129.7
Average guesses needed	2 to the power of 128.6891
At 100 billion guesses a second	174 quintillion years

So the rule that satisfies a website’s complexity policy costs 0.148 bits, which is a rounding error next to what it is often assumed to cost, and next to what a single extra character buys - 6.49 bits.

The same settings at other lengths:

Length	Entropy	Average time to guess
8	50.9 bits	3 hours
12	77.4 bits	32.1 thousand years
16	103.6 bits	2.46 trillion years
20	129.7 bits	174 quintillion years
128	831.0 bits	2.2 x 10^231 years

These are the same numbers asserted in this tool’s test file, so if the formula ever changes without this page changing with it, the build fails.

What it does not do

It does not check the password against a breach corpus, and it does not need to: a password drawn from 90 characters at random has never appeared in one. It does not store anything, so there is no history and no way to recover a password you close the tab on - copy it into a password manager first. It does not know how the other end stores what you give it, which is the assumption that moves the time-to-guess figure the most: 100 billion guesses a second is right for a fast unsalted hash and wildly pessimistic for Argon2.

And it cannot help with the two ways passwords actually fail. Reuse turns one breach into many, and phishing hands over a 128-bit secret as readily as a four-digit one. Entropy is a lower bound on the effort of guessing, not a measure of how safe an account is.