At what length does a password stop making sense?

Question

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.

Answer 1

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.

Answer 2

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

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

It obviously doesn't make sense to choose passwords longer (in bits of entropy) than the hash you're going to use. Nobody will try to guess those since there is no need - your system will happily accept a shorter password found via a hash collision.

For example, if you were to use 128-bit hashes, and your passwords are truly random and include a-zA-Z0-9 (about 6 bits per character), it makes no sense to generate passwords longer than 128/6=22 characters (rounded up). Like I said, for each longer password there will be an equivalent password of 22 characters or less which will be recognized as correct anyway. For 256-bit hashes, passwords of up to 43 characters make sense.

Answer 7

In my view, 8 characters of randomness is (relatively) trivial to remember. There will still be opposition, but it's possible for most people.

16 characters would be getting tricky. Possible for most of the population that need to, but you'd need to be very picky about which systems use it.

24 characters would require a password manager for most of the population.

32 characters is effectively a key. The user is unlikely to remember it themselves.

I would consider a password manager to be, effectively, a key management system with a human interface layer. The people using it will never actually remember the passwords, and will only very rarely actually see them. Make them as long as possible within the system confines is my advice.