Should a password generator validate its output against a dictionary?

Question

If I were to design a password generator, is it best to leave it truly random or validate its output to avoid certain passwords?

For example if my password generator was truly random, it's possible its output could be "password".

Where do you draw the line? Should it just scan for common passwords, or ensure nothing in the entire string matches a known word? E.g. skipping "fg3~nfpasswordh&tr" because it contains "password".

Does doing this reduce the security of my password generator because the possibility space is reduced?

Answer 1

When creating a password generator, use a cryptographically secure pseudo-random number generator (CSPRNG) and trust in the random properties of that system.

Rather than checking if a randomly generated password contains a substring that humans might recognize as a word, instead check that the entire password has not been part of a data breach.

The current biggest threat to passwords are offline attacks against data dumps. Passwords should be stored using a key stretching algorithm, such as PBKDF2, bcrypt, scrypt, or Argon2, which makes it impossible to pre-build lookup tables and greatly increase the time that it takes to attack the passwords.

Additionally, these key stretching algorithms have an avalanche effect: A minor change in any of the inputs will make a huge difference in the output. (Caveat: With an infinite input space and a finite output space, there will be collisions.) Cryptographic hashing algorithms also have this feature. Thus, attackers can not tell how close they're getting to cracking your password, like they can in movies.

Thus, unless you've somehow told your attackers that password contains the word 'password', then it doesn't matter if there are human readable words that happen to appear in the middle of your generated password.

The current largest threat is from attackers that use dictionary attacks based on previously leaked passwords, because they know that users will reuse passwords, and will use known weak passwords in throwaway accounts. The way to mitigate this, according to the NIST standards, is to check the whole of the password against a list of known bad passwords, such as dictionary words, expected patterns, and compromised passwords.

The NIST standard puts the onus of keeping users from using known bad passwords on the site owners, but there is nothing preventing your generator from using a service such as the Pwned Passwords API in the astronomically unlikely (but technically possible) event that your generator using a CSPRNG produces a password that has been leaked elsewhere.

Answer 2

The question is exactly where you "draw the line" (to use your own words). I would guess that the example you give is as strong as most 17 character passwords, even though "password" is a substring, but "12345password1234" is perhaps not.

It's really hard to implement some rules as there will always be some that think they filter out to much/too little. I also like to filter out (theoretically that is, I don't think it has ever occured) passwords that look like some of the passwords I used 15-30 years ago when I memorised every password (I know some of them will have become known by others). Different ideas on what is good enough before/after, and desires to filter out other things (like mine) makes it really hard to do anything useful automatically.

And yes, theoretically you do reduce the possibility space by saying that you don't want certain passwords, but I think it will still be a very small reduction, and attackers probably don't know what you filter out, so they will still have to try those strings.

Answer 3

Don't check against a known list of common passwords as you are decreasing security.

If the password has to be short (4 digit PIN) then excluding common PINs can noticeably reduce security. Once you remove repeated digits etc, there are a lot less possible PINs left.

If the password is longer, then the chance of clashing with a common password becomes negligible, so the check (if it can be done securely) is not worth making.

This assumes the attacker knows the password generator is being used.

Note that it also means less code to write or review...