Password policies for randomly generating passwords

Question

I want to randomly generate a password. I started by using all characters that are typable on a standard QWERTY keyboard. However, many password policies reject passwords with some special characters (for example ^~`'" are characters that are commonly rejected). Other policies require special characters. So far, I have used a strategy that generates a password that includes at least one uppercase, one lowercase, a number, and a not-so-special character (such as a dot or comma), which are not often rejected. Of course, the password is of sufficient length.

However, I have also come across sites which only accepts strings of letters and numbers as passwords.

What are reasonable password policies to support?

Answer 1

I can guarantee you that we could easily find two sites that have entirely incompatible password policies. It'd actually be easy: find one site that requires special characters, and another site that bans them. Done. So there's no one-size-fits-all solution.

I think your best bet is to generate random passwords in a form that'll mostly work for sites - upper, lower, numbers, and a reasonable length. I've used a UUID-type string or even a truncated MD5/SHA1/whatever hash of /dev/urandom in the past. Then give users the option to enable "special characters required [/forbidden]", max length, etc options. A more complex option is to build-in the policies for the weird sites as they come up, but that'd be nightmareish probably.

FWIW, I'm a strong believe that unique passwords (ie, using a password manager) is vastly more important than using strong passwords in most cases (the main exception is when the attacker can perform an offline attack, like a full-disk encryption password). So I would worry more about making the integration easy (and making the password manager itself secure!) than having the strongest possible passwords. I can talk about that all day, happy to expand on it!

Answer 2

You might want to take a look at the password generators in existing password manager tools, such as LastPass. As @RonBowes says, there is no one-size-fits-all policy, and the sad fact is that many sites have policies that mean you can't use a very strong password (Until a few years ago, Wells Fargo bank only permitted 6-8 case-insensitive alphanumeric characters for its online banking, to give the most egregious example off the top of my head) so you can't even just flip between a couple of highly-secure policies such as "very long but only alphanumeric" vs. "relatively short but selected from all typeable characters".

Generally speaking, longer passwords are safer, mostly regardless of the character sets used. For example, randomly selected case-insensitive alphanumerics are still more than 5 bits of entropy per character; a 20-character password from that set is 103 bits of entropy, roughly 11 orders of magnitude harder to crack than a password randomly selected from all typeable characters on a US keyboard but only 10 characters long (66 bits of entropy).

On the other hand, longer passwords can be more difficult to type manually (more places to make errors), especially when the characters are random, and also harder to memorize (much harder, for random characters even from a restricted set). So if people are likely to be manually entering these passwords, you may want to use (or at least offer) less-secure settings.

Also, even bad password policies can be pretty secure if the characters are chosen truly randomly. To take that Wells Fargo policy above, the maximum total entropy of their passwords was almost exactly 41.4 bits, which is a pittance compared to the other examples I gave but still impractical to brute-force over an Internet connection (on average, you'd need to make about 1.45 trillion attempts). That won't hold up to a determined local attacker, but would take a long time over the Internet even if the site didn't have any anti-brute-forcing protection. A typical human-generated (and easily human-memorable) password generated under those rules would be a lot less secure, though!