At what point is password complexity "safe enough"

Question

Obviously the best passwords will be highly complex randomly generated passwords stored in a password vault. For the average user though, this might be a slight overkill.

Assuming that the average user is not nearly interesting enough for a targeted attack by a competent attacker, at what point does a password become safe enough from the most likely attack scenario, a dictionary or bruteforce attack against a large compromised password hash database targeting the low-hanging fruit.

What is the minimum level of entropy that should be met, taking into consideration that the user has no control over the type of hashing applied on the password?

Answer 1

Security is all about balance. There is no "perfect" answer and no "perfect" security. You can always make things more secure, but security has a cost, typically usability. Making good security decisions is based on making a determination about what is important to your needs, what is acceptable risk, what is necessary usability and then setting your security policies based on those needs.

For a site like Wikipedia, password security doesn't really matter since anyone could make an account and modify the same content. There isn't (for the most part) any difference in privilege or restriction, so there isn't a big reason to want to break a password and the risk is minimal.

When dealing with banking information, then clearly the risk is much higher and the level of restriction the password grants access to is higher, so the complexity should be higher. Similarly, anything that has the ability to cause loss of life will generally have even higher security still.

Answer 2

A safe level of password complexity depends on what you are trying to defend against. What is the value of guessing the correct password? How is the attacker guessing these passwords?

Is this just an online attack trying to brute force a login portal? Can you protect this portal with rate limiting or a captcha? Not having these types of anti-brute force systems is more serious than not enforcing a password complexity policy.

Or, are you trying to prevent a hash from being cracked? If the password hash isn't salted then the attacker can pre-compute large rainbowtable of passwords, and really anything under ~12 characters is unsafe. Even if you are using key stretching with bcrypt, scrypt or PBKDF2 the attacker is still able to perform many more guesses than an online attack.

Obligatory XKCD reference.

Answer 3

One basic answer is that a password with 60 bits of entropy is enough -- that's about ten alphanumeric characters (chosen randomly, independently and uniformly, please). For such a password to be practically crackable, the attacker must have substantial computing means (e.g. using the computers of several universities for several weeks) and the hashing mechanism must be laughably weak (e.g. a single MD5 invocation).

Actually shorter passwords should already be strong enough, because if the hashing is weak, then chances are that whatever server uses it has a number of other vulnerabilities which are much easier to exploit than throwing lots of GPU at it.

The really important thing to do, for the user, is to use proper randomness when selecting a password.

(I don't like the term "complexity" for passwords. Complexity is organization, structure. This is exactly what we do not want for passwords. We want white noise. We want the uttermost simplicity of uniform randomness.)