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?

  • 4
    Assuming the password is hashed, then yes. See security.stackexchange.com/questions/42154/… and crypto.stackexchange.com/questions/25252/…
    – user389823
    Commented Mar 24, 2016 at 14:02
  • 12
    I expect you are asking about technical matters when you ask about how security could decrease with increased length. One non-technical way this can happen is that longer passwords can be harder to remember, which might encourage users to write them down, which would be less secure. Commented Mar 24, 2016 at 18:30
  • 2
    It depends on the size of the hash. Let f be your hash function, if you fix the number of bits in the hash then there exist a length n such that f(Σ¹∪...∪Σⁿ) = f(Σ⁺) i.e. every string with more than n characters has a shorter string, of length say k, with the same hash. At that point brute-forcing will simply find the shorter string and all the n-k extra characters are completely useless. More than those m characters are useful only for non truly random password generators.
    – Bakuriu
    Commented Mar 24, 2016 at 21:00
  • 2
    If your password contains a whole dictionary, it definitely is too long.
    – MSalters
    Commented Mar 25, 2016 at 13:33
  • 2
    @ToddWilcox And put the sticky note on their monitor. AviD's Rule of Usability: "Security at the expense of usability comes at the expense of security."
    – jpmc26
    Commented Mar 25, 2016 at 22:01

11 Answers 11


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.

  • 4
    @PhilLello - It's pretty rare that people use unicode characters in passwords (I once had to debug an app that errored when it encountered one) If you do use them, you just need to adjust the estimate of entropy per character. Say you use the full BMP (65k characters) that's 16-bits per character, so an 8 character password gives you 128 bits of entropy.
    – paj28
    Commented Mar 24, 2016 at 14:34
  • 58
    I'll upvote this if you add one word. Entropy. It's 128 bits of entropy that matters, not length. For instance, I can create a password that's all 1s or all 0s that's 128 bits long. But it follows a well known pattern, so it doesn't contain much entropy. Generally the password length must be longer than password entropy, since human generated passwords aren't random but follow patterns (reducing entropy per character). Commented Mar 24, 2016 at 15:20
  • 8
    @PhilLello a lot of sites die when I try to use accented characters in passwords :(
    – SztupY
    Commented Mar 24, 2016 at 16:08
  • 12
    @paj28: not all characters in the whole Unicode BMP are equally used, or easy to type with a single keyboard layout. If you have to switch keyboard layouts multiple times to type your uniform randomly generated Unicode password, then that isn't any easier to type than just using longer password with basic letters.
    – Lie Ryan
    Commented Mar 24, 2016 at 16:21
  • 2
    @PhilLello - The users of the app were mostly English speakers. I think the odd ones that tripped up were security conscious people deliberately using funky characters
    – paj28
    Commented Mar 24, 2016 at 17:31

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.

  • 5
    Interesting approach to considering ease of use as a security feature, rather than a counter-balancing force. Commented Mar 25, 2016 at 5:31
  • 9
    @PeterCordes, a system that is too hard to use will also be bypassed by well-intentioned people, which can lead to vulnerabilities. For example, they may download a free password manager just to do their jobs, not realizing it's Trojan-infected. Users are an integral part of any security effort; we must always recognize they are people first, and they need to be enabled, not fought. Commented Mar 25, 2016 at 13:12
  • 1
    XKCD estimated a four-random-word password at 44 bits (implying 2000 words to choose from), A seven symbol password has more possible combinations than four random words.
    – Simon G.
    Commented Mar 25, 2016 at 17:45
  • 4
    Although the content of this answer is good, I think the OP intended to avoid such answers by writing, "How the user will remember / recall / store the password also doesn't matter". I interpreted the question as meaning the OP was looking for technical reasons why a long password might be insecure. Commented Mar 25, 2016 at 20:35
  • 2
    I think the OP was asking out of curiosity as a technical / math / computers question, not as a practical security question, like @JonBentley suggested. The kind of answer the OP was looking for can be interesting even if not practically useful, and I thought the OP phrased the question in a way that acknowledged that. Commented Mar 26, 2016 at 0:00

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.

  • 5
    Indeed. Some/all UNIX used to truncate passwords to 8 characters in the DES era.
    – Phil Lello
    Commented Mar 24, 2016 at 14:25
  • 1
    Just mentioning this for fun, if the password is long enough, it may be too big for the attacker to save or break his code! like a 1kb string may get into some trouble being saved in an SQL server (since the saving method is usually static)! or a 10Gb string may actually have no space to be saved!!
    – aliqandil
    Commented Mar 25, 2016 at 11:33
  • 1
    @PhilLello And also the old DES-based LM hash had a limit of 14 characters (in two 7-char chunks).
    – Bob
    Commented Mar 25, 2016 at 13:35
  • 3
    "Hashed using the first N characters" can be completely insecure because the first N characters might not contain any entropy. You might want to point out that these implementations are explicitly baleful.
    – djechlin
    Commented Mar 26, 2016 at 1:02

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


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


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.

1 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

  • 1
    The storage medium is irrelevant to this question. It is assumed no shenanigans and best practices by the site. Just password length vs security. Not even how the user will remember such long password is relevant here. Commented Mar 24, 2016 at 20:25
  • 2
    @Mindwin: The OP says: "I am interested in the security of the password regarding cracking it only.". I presented a case where having a longer password can be dangerous due to the fact that it is longer (because it may be easier to crack)
    – WoJ
    Commented Mar 24, 2016 at 20:30
  • I worked in a system which had this exact flaw - many people had used secure, long passwords, and yet our crufty old DES encryption truncated to only 8 characters, trivially crackable. Secure keyphrases and passwords made of keywords with appended randomness (a very common pattern of password creation, albeit weak: "password1234!") were more easily crackable by this system than those which were shorter but more random: they were hoist by their randomness. This builds on other answers saying the security is only as good as the number of bits of entropy in the hash. Commented Mar 25, 2016 at 21:18
  • @WoJ, this is not a case where the longer password is more dangerous; password and passwords would both be just as dangerous as your proposed very long password. It is rather that the extra length doesn't reduce danger as expected. (To be sure, this is part of what is asked for in the title, but I think it's still an important distinction to make.)
    – LSpice
    Commented Mar 27, 2016 at 21:18
  • @LSpice: I believe that this is a case where a longer password is more dangerous. People are lured into thinking that a longer password will be more secure while this is not true - a shorter one (but more complex) would be better in that case. The extra length assumes that all of the password will be taken into account. But we may be into semantics here :)
    – WoJ
    Commented Mar 28, 2016 at 18:30

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.


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.

  • 2
    Your concluding paragraph isn't valid. For the sake of the argument, I'll take your figures as being correct i.e. 38 characters is the limit of what is possible to brute force given all the available energy in the universe. However, for each individual attempt during the brute force, there is some probability it will be successful and the search can conclude before it is completed. 39 characters is still more secure than 38 because it reduces that probability. Commented Mar 25, 2016 at 21:19
  • @JonBentley You are correct and I have edited my answer in response and because I could not calculate logarithms yesterday for some reason. The OP asked for a limit and this is the only limit I know of.
    – Simon G.
    Commented Mar 27, 2016 at 14:30

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

  • Sérgio, check the assumptions on the question. Dictionaries are ruled out, and it is assumed best practices for storage. But you got a good point with the max hash entropy. Commented Mar 24, 2016 at 20:24
  • I understand the approach, but that was my point with the batterystaple example. Even if a password is not in a dictionary, it can be if it's likely to be used. If you are thinking of a password as an uniformly distributed string of printable characters, then it is not a password, but a weirdly encoded cryptographic key. In that case, the focus would be only about entropy (and randomness in the generation), but the implications in usability would be enormous. Commented Mar 24, 2016 at 21:17
  • 1
    @Mindwin A dictionary attack will contain more 'hard-coded' values than just the words found in a given language. Eg. "12345678" will be in it, as well as its substrings. Password1, !Password1, !P@ssword1, and many other variants will also be in the 'dictionary'. Any time you see a list of the most X commonly used passwords, all of the passwords mentioned are added to a dictionary somewhere for later reference. So excluding dictionary words doesn't mean you're excluding dictionary attacks.
    – Shaz
    Commented Mar 25, 2016 at 19:38
  • 1
    It's sad that these attacks are called "dictionary" attacks, rather than "wordlist" attacks. I used to believe that since welsh placenames were not dictionary words, I was fine using them as passwords. ...I got better! Commented Mar 25, 2016 at 21:19
  • I can only suppose that it is influenced by the fact that "dictionary" is in several languages a composed word that could be translated as wordbook. Or the attempt to make an analogy with something in the real world. But it can be very misleading, that's true. Commented Mar 25, 2016 at 21:28

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

  • I believe this is incorrect Alexey. Some password storage algorithms do have input length limits. Commented Mar 24, 2016 at 14:03
  • 2
    a particular algo's can have limits, maybe. but generally speaking - there's no limits Commented Mar 24, 2016 at 14:05

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"


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.

  • hey hildred, thanks for participating, but the question assumes best current community accepted practices (bcript + salt / etc). Commented Mar 28, 2016 at 19:15
  • At the time of implementation, this was the best practice.
    – hildred
    Commented Mar 28, 2016 at 19:17

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.

  • Most of this looks like a response to another answer and not a direct answer to the question asked.
    – schroeder
    Commented Mar 21, 2021 at 23:44
  • And then what is a direct answer is little different from the highest voted answer.
    – schroeder
    Commented Mar 21, 2021 at 23:51
  • My answer provided a lot of insights with actual backing and math on limitations regarding energy costs or actual limits of physics, with linked resources to support those claims. You opted to remove that because a similar existing answer which lacks that information was available? Commented Mar 22, 2021 at 2:44
  • The highest voted answer that you compare the first part of my answer to (which is all that remains with your edit), has different claims. 100-bit of entropy if bcrypt is in use seems somewhat specific yet vague.. At 1 attempt every 5 minutes, exhausts 24 bits entropy in approx 160 years (2^24 / (12*24)) / 365 = ~160 which can ignore any slow hash like bcrypt, the attack vector isn't slowed by it. By contrast I cited the bitcoin network hashrate, with all that processing power 100-bits exceeds a lifetime: (2^100 / 150e18 / (60*60*24*365))= ~268 years. 268 years at the current rate. Commented Mar 22, 2021 at 3:27
  • No, I removed it because, as I said, it was a response to another answer and not an answer itself. You are saying that the calculations are different in this one claim, but that's irrelevant to the question. Your answer does not address the question.
    – schroeder
    Commented Mar 22, 2021 at 7:43

You must log in to answer this question.

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