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.

  • 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, 2013 at 20:15
  • Which hash function is your server going to use to store credentials? This choice will have much more impact on security than the password length you're going to choose. Dec 4, 2015 at 8:40
  • A key question here is whether the users will only ever use the password manager to autofill the passwords (in which case a very long password will not inconvenience the user), or if they will ever have to do something like use a password manager to read a password on a mobile device and then enter it manually on another device (in which case a shorter password length will be required).
    – JonnyWizz
    Dec 4, 2015 at 8:56

7 Answers 7


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.


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
  • 3
    While unfeasible, I have a comment on what limit a password can have before it stops making sense. It depends on how the password is stored (hashed). If the password is stored "securely" using sha-2, which have 256 bit of entropy, and the password contain more than 256 bits of entropy, it is a certainty that there will exist collisions where password A and B both leads to hash C. This is due to the pigeon hole principle. If the password contain all printable letters (100), it will not make sense of having a longer password than 39 characters due to this "problem". Mar 6, 2015 at 9:45

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


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.

  • 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.
    – Adi
    Dec 9, 2013 at 4:51
  • 1
    Without doing the math myself, I suspect he meant 10^100 years. Dec 9, 2013 at 4:59
  • @StephenTouset Yeah, it wasn't until after I posted my comment that I realized the possibility.
    – Adi
    Dec 9, 2013 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.
    – JZeolla
    Dec 9, 2013 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.


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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .