Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
2  
Depends what type of site... E.g. is this for a banking site? Dating site? An online game? Online dating bank game? –  AviD Dec 19 '12 at 16:26
1  
This is a risk based decision; the answer depends on the risk tolerance of the person/function who accepts the risk. I'm not sure that there is any meaningful answer to the question. –  Mark C. Wallace Dec 19 '12 at 16:47
1  
Agree with AviD here - more details needed! –  Polynomial Dec 19 '12 at 16:59
    
Taking the devil's advocate view, why is this question meaningful? It seems to be slightly akin to asking why we boil the sea when it comes to HTTPS. "Yes, yes, I know HTTPS is the answer, but I don't want to use it!" We know that 128 bits of entropy is considered sufficient, so why attempt to go lower? What is the question intending to solve? –  Jonathan Garber Dec 19 '12 at 17:10
add comment

3 Answers

up vote 3 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.