This widget generates passwords. You probably shouldn't use it.
This page was written by me, and I'm just some guy on the internet. You have no reason to trust me about anything. You might choose not to verify low-consequence things I say, but you cannot afford not to verify that I won't do anything Evil with your password.
Is my generator unbiased, or will it generate the same passwords over and over? After generating a password, will it somehow send the result to me? Is there some other kind of backdoor that will allow me to know what your password is? You have no way to know without very carefully reading all of my code — and even then you should be wary.
This generator produces 8-character passwords with about 50 bits of entropy (if you trust me and my math). This just barely meets the NIST guidelines.
In order to pack as much entropy as possible into those 8 characters, I allow any of the 94 printable, non-space ASCII characters. This means that the password will usually include non-letter characters, and will almost certainly be unintelligible. That makes it difficult to memorize; if you use a password like this, you should probably be storing it in a password manager instead of your brain. If you need a Very Good password you can store in your brain, I recommend the Dice Password Generator, which allows you to bypass internet trust issues by rolling physical dice yourself.
This generator also ensures that its output will meet certain rules:
These restrictions reduce the entropy by about 2 bits,
compared to an 8-character password without those rules.
Note that the string Passw0rd meets these requirements,
and it is a terrible password you should never ever use.
Since composition rules do not ensure high-quality passwords,
and since they reduce entropy,
and since they can encourage users into a false sense of security
after trivially modifying bad passwords,
NIST discourages the use of such rules.
Unless you have a specific reason to meet these rules, you should probably use the password generator built into your browser, or built into your password manager. You've already chosen to trust those things, so using their password generators won't create additional risk for you.
The procedure used by this generator is:
You might imagine an algorithm which avoids retries, such as:
Sadly, this algorithm does not produce passwords with the maximum possible entropy; it has a slight bias towards including more letters and digits than necessary. The existence of this bias can be proved with a bit of counting arithmetic:
How many valid passwords are there? Assume for a moment that the 1st character is a lowercase letter. The total number of 7-character strings which may follow is 947. But (94-26)7 of those do not contain an uppercase letter, (94-10)7 of them do not contain a digit, and (94-36)7 contain neither. Therefore we have 947 - 687 - 847 + 587 ≈ 31 trillion valid 7-character strings. Multiply this by the 26 possible lowercase letters, and then by 2 since that letter could actually have been uppercase instead. This gives about 1.6 quadrillion valid passwords.
How many valid outcomes does the no-retry algorithm have?
Multiply that out, and we get about 500 quadrillion possible outcomes. This is a lot more than 1.6 quadrillion, so there must be multiple ways of generating some valid passwords. In fact, a bit of division tells us there are, on average, 312.002 ways of generating each password — and that .002 is a problem. Since the average number of ways to generate a password is not an integer, some passwords must be more likely than others.
We haven't determined here which passwords are more likely,
and even if the number of outcomes were an integer multiple of the number of valid passwords,
we wouldn't have disproved the existence of a bias.
If you're so inclined,
I recommend analyzing a smaller version of the problem,
where the lowercase alphabet is just {a, b},
the uppercase alphabet is just {A, B},
the full set of valid characters is just {a, b, A, B, !, @},
and the password is only 4 letters long.
In any case, the "generate something definitely valid, then shuffle it" algorithm is right out.
The only input to this generator is randomness, but even random bits have to be handled carefully to avoid introducing bias to the results.
For example, suppose we are trying to simulate a 6-sided die. We have 6 outcomes, which is less than 8, so 3 random bits should be enough. But when we map bit sequences to outcomes, we have a problem:
If we get a 6 (1102) or 7 (1112) from our random bits, we cannot map that to any face of the die without making that face a more likely outcome than the others. Our only option in that case is to give up and ask for 3 more random bits, and keep doing so until we get a value 0-5.
We can make rerolls less likely by asking for more bits up front.
For example, we could start with 5 random bits (giving us a value 0-31)
and map each random value R to die face (R % 6) + 1.
But we will still have to discard R if it's 30 or 31,
or that bias towards ⚀ and ⚁ sneaks back in.
This is one of the reasons we cannot use Math.floor(Math.random() * 6) + 1.
The number of possible outcomes from Math.random()
is not a multiple of 6,
so there is still a bias
(albeit vanishingly slight)
towards certain die values.
The other reason is security:
we ultimately want to be generating passwords,
and Math.random gives pretty low-quality randomness.
Therefore we need the cryptographically-secure pseudo-random number generator (CSPRNG)
provided by crypto.getRandomValues().
I got a little bit fancy with this generator's RNG. I know that I am going to ask it for 8 random numbers; that 1 of those will be 0-52; and that the other 7 will be 0-94. This is mathematically equivalent to asking for a single random number between 0 and 52×947 (which is about 251.6). So that's what I do, starting with 64 random bits. If I get a number right at the very top of the range I will have to ask for a new one, but this happens less than 1 time in 12,000.
Anyway, click this button to generate a password.