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.

I'm going to recommend that our users start using a password manager and start creating strong random passwords.

Though I don't know what size of a password to recommend. Is it possible for a password to be so strong that it stops making sense?

I want them to have passwords that are strong, random, and long enough so that even if the hashed password table were stolen, that no brute-force or rainbow attack will ever* be able to guess it.

Where ever* is something reasonable. Of course with sufficient time and resources any password can be brute-forced. But at some point in password strength, I think it must stop making sense. I don't want to sound like I'm going overkill and protect their password from a 4th dimensional being or something.

Oh and a 64 character websafe alphabet is what I'm thinking about recommending.

share|improve this question
1  
if you are using a password manager why not just make it max length, they won't be trying to remember it or writing it down. Also, why not overkill? –  TruthOf42 Dec 9 '13 at 20:15

5 Answers 5

up vote 16 down vote accepted

Armed with the knowledge that a search space of 128 bits is more than sufficient for the foreseeable future; with 192 bits being ridiculously high; and 256 bits being something that is unimaginably impossible to cycle through, and assuming that your character set is alphanumeric upper and lower case English, randomly-generated, then we can say that:

  1. A password of 22 characters is more than sufficient for the foreseeable future.

  2. A password of 33 characters is ridiculously long .

  3. A password of 46 characters is just... I don't know what to say.

So, to put it in one line: With an alphanumeric upper/lower character set, it starts making less sense after 22 characters. When does it stop making sense? Somewhere between that and 33 characters, very early.

share|improve this answer

The required length of the password is dependent on the set of characters it is composed of. An all-lowercase password would need to be longer than an alphanumeric one. So instead, we look at the "keyspace" of the password measured in bits (or "search space" if you're coming at this from the perspective of the attacker).

For the immediate future, a password in the range of 70 to 90 bits is probably sufficient. For the foreseeable future, something on the order of 130 bits will probably get you there. For the sci-fi future, 256 will probably never be crackable by anything ever encountered.

As far as how many bits there are in a given password, just take the size of the alphabet (a-z has 26 possible letters, for example, while a-z plus A-Z plus 0-9 has 26+26+10=62 possible letters), calculate the log base 2 of that number (4.70 for 26 letters, and 5.95 for 62 letters) , and then multiply that result by the number of characters in your password.

Since math is hard, here's a table pre-calculated for you.

Length    a-z       a-z,A-Z,0-9
12       56.4        71.5
14       65.8        83.4
16       75.2        95.3
18       84.6       107.2
20       94.0       119.1
22      103.4       131.0
24      112.8       142.9
share|improve this answer

[Disclosure: I work for AgileBits the makers of 1Password]

I have actually written about this for our users. If they use our password generator and even restrict it to mixed case letters alone, the 23 characters gives them in excess of 128-bits of entropy. $$log_2(52^{23}) \approx 131$$. 128 bits is more than sufficient for any password.

Of course if the password is not chosen from a uniform random distribution, then the question is much harder to answer.

share|improve this answer

I would say that a password of x length no longer makes sense when it takes so long for the user to authenticate that it is noticeably hindering performance. With technology where it is today, I see absolutely no problem with a 64, or even a 100 character upper/lower+number+symbol password. Regardless of the hashing algorithm, a pure bruteforce (without using any other subversive techniques) is not feasible.

Example: A password using ~426 (rounded down to the nearest 1) bits of entropy. At 7 billion hashes a second (MD5), and an attack cost of 2^n-1, that would take 3.9 * 10^110 years (Assuming 24 hours a day and 365 days a year). I'm comfortable with that.

For sake of argument, I did the same thing for a password of the same length and randomness, but uses only the lowercase English alphabet. That ends up being about 353 bits of entropy (Rounded down to the nearest 1). That would take 4.2 * 10^88 years (Assuming 24 hours a day and 365 days a year).

For more details about password strength and entropy, look at appendix A here.

share|improve this answer
    
I just have a hunch that your calculations are extremely incorrect. Having 462bit and 39429 years in the same sentence sounds very ridiculous to me. A lowercase English alphabet randomly-generated password with an entropy of 462 bit has a length of about 97 characters. The search space for that is is somewhere in the 10^137. That's 1 with one hundred thirty freaking 7 zeros. That's gigantic!!! GIGANTIC! At 7 billion hashes/second? Heh, try something like 10^119 years. –  Adnan Dec 9 '13 at 4:51
1  
Without doing the math myself, I suspect he meant 10^100 years. –  Stephen Touset Dec 9 '13 at 4:59
    
@StephenTouset Yeah, it wasn't until after I posted my comment that I realized the possibility. –  Adnan Dec 9 '13 at 5:20
    
Yeah, I did. I fixed it... For some reason when I copied it from my working document it didn't bring the ^. It was also wrong in the second example, it had * 1088 years. –  Steel City Hacker Dec 9 '13 at 12:07

I think the question itself is somewhat incomplete.

@Adnan's answer is pretty close to being completely correct. However it does leave out the fact that many systems artificially limit the character set that may be used, which in turn changes the results from the length calculations. For example, a system that only allows usage of A-Z, a-z and 0-9 is much easier to crack at 22 characters than one that also includes punctuation and/or non-printable characters in it's allowed range. In other words, a larger range of acceptable characters can result in a lower number that's required for the same level of "protection."

The next item is really around usage. Namely that a pass phrase is much easier to remember than a random string of characters and can certainly be longer than the proscribed 22 or 33 characters while allowing the user to easily recall them. So even if 33 characters is considered "ridiculously long" from a technical perspective - meaning that it requires a password manager - it may not really be from a user perspective.

I routinely use pass phrases that are in the 40 to 60 character range. These are easily remembered and, based on the calculations, unfeasible to attempt cracking. Unfortunately, most systems simply don't allow for that length.

Instead of a recommendation for a password manager I would simply educate the users on pass phrases while requiring a certain minimum length. To help things along I'd look at the areas the app is to be used in and make sure that common punctuation for those locales are allowed.

share|improve this answer

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.