Is there a threshold for a password so long it doesn't get any more secure or even becomes insecure?

Question

I always hear "A long password is good, a longer password is better". But is there such a thing as a "Password is so long it is becoming unsafe" or "Password is long enough, making it longer won't matter"?

I am interested in the security of the password regarding cracking it only.
Not if it can cause a DoS overload the servers while hashing, or if the vendor thinks otherwise.

Also assume the password does not contain any dictionary _{it'd be in comments anyway.} words, is stored using best practices, has a strong and unique salt, and relevant entropy per character. How the user will remember / recall / store the password also doesn't matter.

I agree that longer / passwords / are safer. I'm asking about the upper limit.

Is there a length (or entropy size) where making the password longer no longer (sic) matter, or even weakens its security? I know it depends on the hashing algorithm, if the upper limit for a given algorithm exists and is known, what is it?

Answer 1

128 bits (of entropy)

The main purpose of a longer password is to prevent brute force attacks. It is generally accepted that 128 bits is beyond anyone's capability to brute force, and will remain so for the foreseeable future. You see this figure in a few places, e.g. SSL ciphers with 128-bit or greater key length are considered "high security" and OWASP recommends that session tokens be at least 128-bit. The reasoning is the same for all these - 128 bits prevents brute force attacks.

In practice, if a password is made of upper and lower-case letters, numbers, and a little punctuation, there is approximately 6 bits of entropy in each character, so a 128-bit password consists of 22 characters.

A password can be compromised in ways other than brute force. Perhaps there is a keylogger on the client system, or the user gets phished. Password length makes almost no difference to these attacks - even a 1000-bit password would be captured just the same. And these attacks are common in practice, so it really isn't worth using passwords that are too long.

In fact, you can get away with a bit less than 128 bits. If the password is hashed with a slow hash function like bcrypt, that makes a brute force attack harder, so 100-bits (or thereabouts) completely prevents brute force attacks. If you're only concerned with online attacks, and the site has a lockout policy, then you can get away with less still - 64-bits would completely prevent a rate limited online brute force attack.

Answer 2

Can a password be so long as to be insecure? Yes.

When you look at the broad picture of security in your organization, security doesn't only mean "protect accounts with unguessable passwords." Security must protect the whole organization with the "CIA Triad" of Confidentiality, Integrity, and Availability. Beyond a certain threshold of password length, confidentiality and integrity do not statistically improve, while availability goes down due to poor usability. A system you cannot log in to is just as unavailable as one that is down.

If you force your user to type a 22 character password made up of all random, mixed case letters, numbers, and symbols, your users will be more prone to mistakes. Consider that a user may be under stress to respond immediately to a critical situation. Fumbling with a long password may cause a 3-tries lockout and take the user so much time to reset that they can't address the situation in a timely manner, and a disaster results. That long password prevented availability; instead of protecting the organization, it caused it harm.

How much time do your users waste entering passwords? The longer the password, the slower the entry. Subtract that expense right off the bottom line. That's part of the cost of security, money that could have been spent elsewhere. A 100 character password would cost you more than a 20 character password, while providing no measurable decrease in risk. Time and money are assets, and a too-long password spends them without producing added benefits.

With all this, am I advocating poor security of 4 digit PINs, so the users are faster, happier, and make fewer mistakes? Of course not. What you need to do is balance the entropy provided by the password with the psychology of using it.

While most users won't be able to remember a 12 character password made from 70 letters, numbers, and symbols, they could probably remember a five word passphrase; so consider a diceware approach to achieve similar entropy. Five random-but-familiar words are likely easier to remember and type than 12 random symbols while providing quintillions of possible combinations; six diceware words provide even more security than the 12 character passwords.

If it has to be characters for some reason, make sure to choose them from the set of unambiguous characters. Don't force the user to dance on the shift key, or type random symbols. If you need the entropy from a 12 random character password that draws from [a-z][A-Z][0-9][!-*], you can achieve a similar level of entropy using just [a-z] and expanding it to 15 characters.

Or consider other tools, such as authenticating tokens, biometrics, or smart cards, and have those supplement a shorter PIN.

Security systems must be usable, or they interfere with the organization to its detriment.

Answer 3

Increasingly longer passwords don't become insecure, but at some point they stop becoming more secure.

Based on the assumptions you mention, it seems likely that the password is truly random and stored using bcrypt (state of the art password storage). Bcrypt has a length limit of somewhere between 50 and 72 characters, depending on the implementation. So a password longer than that will either not be allowed, hashed using only the first N characters, or something similar. Basically, longer will not be better (though it will be no worse).

One could also argue that, once the password is secure against a brute-force attack on the password hash from now until the end of the universe, making the password longer doesn't make it more secure. Even if you make wild assumptions about an attacker's hardware, a truly random password with 20-30 characters will be secure until the end of the universe. Hence, a longer password won't be more secure.

Answer 4

One case where a longer password may be in fact weaker than expected is with systems which truncate the string you input as a password. Consider

passwordsogoodtahtittakestrillionyearstobreakitgoaheadtryme

This password is extremely good¹ except when you have a system which actually sees it as

password

because it accepts only 8 characters. The rest is silently discarded so you always type passwordsogoodtahtittakestrillionyearstobreakitgoaheadtryme, the system accepts password from it and everyone is happy.
Including the hacker who tries this combination first.

¹ _{yes, also because it has dictionary words which make it easier to remember than some useless capital-digits-specialchars triad promoted by mathematically-impaired security consultants}

Answer 5

I see a couple of comments alluding to this, but no answers that state it clearly, so I'll add it here.

Yes, there is a limit to the length you can add to a password before you no longer get any more security from it if the password is hashed (and let's hope it is). This is because an attacker doesn't need to know your password, he/she only needs to know a string that hashes to the same output. Therefore, if you have a password with more entropy than the output of the hash algorithm, there will almost definitely be a shorter string that produces the same output because of hash collisions. At that point, it doesn't matter how much longer you make the password, you will still only get the same output entropy.

This of course means that the attacker would have to brute force the hash until a collision is found, which will be practically impossible for secure cryptographic hashes, but you asked for a theoretical limit, not a practical one.

Answer 6

The Landauer Limit specifies the theoretical maximum possible number of single bit changes you can do with a given amount of energy. Let's say you have access to the world's 20 most powerful power stations, all operating at full capacity for 100 years. That would give you 5*10^20 Joules of energy with which to do your calculations. Let's assume you have a modern computer which only takes a million times as much energy as theoretically required. With that much energy, that good a computer cooled to -270 Celsius, the laws of physics say that you could only work through 2^124 combinations of input.

If you are willing to completely destroy the entire planet, converting with perfect efficiency to energy, and have a computer that operates at the Landauer limit again cooled to -270 Celsius, then you could enumerate 2^213 possible input combinations.

If you can somehow destroy all matter in the entire universe and harvest all the dark energy, then your theoretically perfect computer can still only work through 2^233 combinations.

Hence, 2^233 combinations is the point at which a brute force attack is no longer guaranteed to succeed given enough investment of time and energy. There is no possible investment big enough.

There is always luck. No matter how many bits you have, it is possible a guess could be correct. One therefore chooses an acceptable risk. There is no way to get a zero risk, and no way to define "acceptable" in universal terms.

Theoretically, a computer the size of the earth and operating at the Bremermann Limit for computational speed would crack a 256 bit password in under two minutes. However, as just calculated, there is insufficient power in the universe to make that effort. The time it takes to crack with theoretically ideal equipment does not give us an "acceptable" limit.

President Obama has ordered the creation of an exaflop computer by 2025, hoping it will be the world's fastest computer when it is built. What chance does an exaflop computer have of cracking a 2^233 bit password in the 5 billion years remaining before the sun explodes? Well that is 1.6*10^34 guesses or less than 2^114 guesses. That's one chance in 2^119 (6*10^35) of cracking the password before the sun explodes.

Acceptable? Who is to say? It is very difficult to put such odds into perspective as they are so unlikely. Winning the lottery jackpot this week, next week and the week after as well? Way more likely than cracking the password before the sun explodes five billion years from now.

233 bits of entropy can be represented with 36 characters drawn from the 95 printable characters of US-ASCII. An attacker cannot guarantee to crack such a password by brute force even using all the resources of the entire universe to do so, and the odds of them cracking it using just the technology existing today are very very small.

This is the only limit I am aware of that is imposed not be the choice of algorithm or the person that has to remember the password but by the actual physical laws of the universe.

Answer 7

By default, the answer of a question of the form can [bad thing XYZ] happen with passwords is yes. There is always a room for specific comments, but the fact remains that passwords are one of the least natural security tasks given to a person, and that person will, almost certainly, favor efficiency over security.

If you choose a long password that is not in a dictionary, chances are that the password is a random string of characters that are hard to remember. As a result, the user will need to find shortcuts to actually use his system without too much hazzle (for users, security is normally an obstacle to achieve the tasks that actually have value): write it down, keep it on the clipboard, plug a USB dong that types the password automatically... you name it.

The Battery Horse Staple XKCD comic became famous at producing longer passwords that are more memorable, but, as a result, put correcthorsebaterrystaple into every dictionary. So, in general, it is hard to produce usable long passwords.

That's it for the practical liability. Now let's see a bit of numbers. Let's suppose that you don't store your password in plaintext, but you hash and salt it. In general, let's say that there is no easier way to crack the password storage than obtaining a collision for the stored password. In that case, each password hash will have a fixed length: let's say 256 bits for SHA-256. Then, you have at most 2²⁵⁶ values to store. Granted, that's a lot, but that's also your "limit". If you store passwords with more than 256 bits of entropy, you'll not keep that additional entropy anywhere. It is not less secure, but, as the answer of Neil pointed in relation to bcrypt, there won't be any gain from longer passwords.

Answer 8

no limits, actually. The limit would be possible for a known-weak hashes where a substitution attack is well-documented and measurable.

Answer 9

When talking about passwords it's important to take in to account all vectors.

For example the password "password" will take 2.17 seconds to brute force. "p455w0rd" takes 29.02 seconds and "p455w0Rd!" takes 2.4 months. Important: Were talking about brute forcing a password, these three examples would take less then a second in a dictionary based attack.

In contrast "thisisalongpassword" takes 2.5 million centuries, while "th1sIs4l0ngPa55w0rd" takes 36.72 centuries. However by using the more complex password you increase the likely hood of someone writing it on a sticky note and sticking it on their monitor.

So while larger entropy is better from a brute force standpoint, it does reduce the over all security of a system by increasing the likely hood that people will be people and do insecure things, thus increasing the vulnerability in other attack vectors.

To look at another example, lets say you force you users to use a pass-phrase length password. So the user chooses "tobeornottobe". If a hacker went with brute force alone, this would take 9.85 months. But because a hacker will use dictionary attacks and other heuristics, this is likely to take minuets. If the same user used "2b0n2b", then brute force alone would take 0.02 seconds, but dictionary attacks would be useless. The goal is to find a sweet spot between easy to remember, brute force hard, and dictionary hard. If you make your password policy stray to far from one of those goals, then you have made the overall password weaker.

The answer

There is no upper limit where more entropy will cause a password to become weaker. There is an upper limit when talking about using a password in the real world. The upper limit is the point in which the users of the system can no longer use the password with out using some insecure means to remember it, thus opening you for other vectors of attack.

Time to brute force passwords is based on https://www.grc.com/haystack.htm at "Offline Fast Attack Scenario"

Answer 10

Yes, there is one case where a longer password is less secure, but no one should use DES passwords anyway these days as they are trivial to crack anyway. Some implementations of DES actually were less secure and used less entropy when the password was longer than eight characters! The workaround was to truncate the password to eight characters before hashing. If you find anyone still using DES based password hashes they have other problems as well. It is also theoretically possible that a similar flaw may affect other password hashing algorithms (I think some versions of lanman had a similar issue), but most people who design password hashes learn from the lessons of history and I am not aware of a modern published password hash function with this issue.

Answer 11

For passwords, if you know more about the security implementation involved, one using best practices may very well let you be safe with just 44 bits of entropy.

That assumes you're not being targeted by someone determined to recovery your password regardless of the cost (although it may get to a point that it's cheaper to finance alternative methods than password cracking which can still require certain conditions to first be met to be effective).

If you're uncertain about the services security practices, 64-bit is safer and quite manageable with Password Management software, or diceware passphrases for easier memorization. Again, that assumes the attacker lacks the financial resources and time required to allocate to acquiring your password, it would have to be valuable enough to justify that cost otherwise.

If a service has poor to no security practices, the amount of entropy may be moot under certain attack vectors. If there is no key strengthening through a properly configured slow hash algorithm / KDF and other means to raise the difficulty of an attack, but there is still some security in place to deter the attacker, you may be able to raise the entropy further as a defense.

128-bit should be more than sufficient.