91

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?

Community
  • 1
Mindwin
  • 1,118
  • 1
  • 8
  • 15
  • 4
    Assuming the password is hashed, then yes. See http://security.stackexchange.com/questions/42154/does-it-make-sense-to-choose-a-longer-password-than-the-output-of-a-hash and http://crypto.stackexchange.com/questions/25252/password-length-versus-hash-length – user389823 Mar 24 '16 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. – Todd Wilcox Mar 24 '16 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 Mar 24 '16 at 21:00
  • Concerning the first question, you're making a fundamental mistake in your thinking: a password you cannot remember is not by definition less secure because you cannot remember it. It's simply so secure even you yourself don't have the access. The problem starts when you start writing it down, or writing down hints. This will help *you* remember the password but obviously anyone else who has them will *also* be able to guess the password. – Cronax Mar 25 '16 at 08:47
  • 2
    If your password contains a whole dictionary, it _definitely_ is too long. – MSalters Mar 25 '16 at 13:33
  • Call me Ishmael... – Wayne Werner Mar 25 '16 at 14:48
  • 1
    I have been known to set a WiFi password to the longest random collection of characters that I can (63 characters). A friend remarked that it was ridiculous as given how WEP was defeated due to a flaw in the protocol, it's more likely that a weakness in WPA2 or the algorithm chosen will be discovered than someone bruteforcing a WiFi password longer than 16 characters (128 bit) and so anything longer than 16 is only making it frustrating to type. – Matthew1471 Mar 25 '16 at 16:24
  • See also http://security.stackexchange.com/questions/15653/recommend-length-for-wi-fi-psk – Matthew1471 Mar 25 '16 at 16:32
  • 2
    @ToddWilcox And put the sticky note on their monitor. [AviD's Rule of Usability](http://security.stackexchange.com/a/6116/46979): "Security at the expense of usability comes at the expense of security." – jpmc26 Mar 25 '16 at 22:01

11 Answers11

81

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.

paj28
  • 32,736
  • 8
  • 92
  • 130
  • Any idea how that length varies with multibyte UTF-8 encodings? – Phil Lello Mar 24 '16 at 14:22
  • 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 Mar 24 '16 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). – Steve Sether Mar 24 '16 at 15:20
  • That surprises me, for example Chinese, Japanese, Sanskrit or Cyrillic passwords in a multilingual system. – Phil Lello Mar 24 '16 at 15:44
  • 8
    @PhilLello a lot of sites die when I try to use accented characters in passwords :( – SztupY Mar 24 '16 at 16:08
  • 11
    @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 Mar 24 '16 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 Mar 24 '16 at 17:31
  • @LieRyan: Not to mention that quite a few systems will be applying NFC/NFD or various other entropy-destroying transformations to passwords. They probably shouldn't be doing those things, but since you don't control the system, that's little comfort. – Kevin Mar 25 '16 at 02:51
  • 1
    I agree that 128-bits of entropy is the correct answer, and is "good enough" for all but the most paranoid. However, when quantum computers enter the picture, this is no longer true, due to Grover's algorithm: it forces us to double this number. 256-bits is an even better answer, as it protects against even quantum algorithms. – Jay Sullivan Mar 26 '16 at 20:48
38

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.

John Deters
  • 33,650
  • 3
  • 57
  • 110
  • 5
    Interesting approach to considering ease of use as a security *feature*, rather than a counter-balancing force. – Peter Cordes Mar 25 '16 at 05:31
  • 8
    @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. – John Deters Mar 25 '16 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. Mar 25 '16 at 17:45
  • @PeterCordes As the saying goes, "Security at the expense of usability comes at the expense of security" – Kevin Mar 25 '16 at 18:37
  • @SimonG., thanks. I did the math then updated the answer. Diceware provides 7776 words, so 7776^4 is about a quadrillion, 7776^5 is in the quintillion range; and 7776^6 is in the sextillion range. A 12 character password is at the smaller end of the sextillion range. The fastest homemade SHA-1 cracker I've seen clocked over 348 billion hashes per second. We can expect more from a well-funded adversary, but only to a point: the costs are high and go up exponentially. – John Deters Mar 25 '16 at 19:50
  • 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. – Jon Bentley Mar 25 '16 at 20:35
  • @JonBentley, that's exactly the problem. Considering only the technical aspect of "how many characters" sets aside the importance of the security of the organization in favor of playing math games, which is not a responsible approach. When comparing security practices, you must always compare the risks, which is not the same as the number of bits of entropy in a password. – John Deters Mar 25 '16 at 20:43
  • 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. – Peter Cordes Mar 26 '16 at 00:00
  • The harder you make it for me to remember my password the more likely I will be to write it down and reuse it on other sites. Don't only obsess on the part of security that you have control over. Hard to use security isn't security. – candied_orange Mar 28 '16 at 13:45
  • 1
    Intuitively you'd expect passwords to have poorer memorability-per-bit-of-entropy than passphrases, but this finding is not always borne out in studies, e.g, https://cups.cs.cmu.edu/soups/2012/proceedings/a7_Shay.pdf – James_pic Mar 29 '16 at 08:43
  • That is a really useful study, thanks for posting the link! – John Deters Mar 29 '16 at 15:15
  • 1
    The last sentence can also be stated as what we now call [AviD's Law](http://security.stackexchange.com/questions/6095/xkcd-936-short-complex-password-or-long-dictionary-passphrase/6116#6116): "Security at the expense of usability comes at the expense of security." – Moshe Katz Mar 30 '16 at 18:04
31

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.

Neil Smithline
  • 14,621
  • 4
  • 38
  • 55
  • 4
    Indeed. Some/all UNIX used to truncate passwords to 8 characters in the DES era. – Phil Lello Mar 24 '16 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 Mar 25 '16 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 Mar 25 '16 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 Mar 26 '16 at 01:02
10

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

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

WoJ
  • 8,957
  • 2
  • 32
  • 51
  • 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. – Mindwin Mar 24 '16 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 Mar 24 '16 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. – Dewi Morgan Mar 25 '16 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 Mar 27 '16 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 Mar 28 '16 at 18:30
6

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.

Kevin
  • 160
  • 5
5

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.

Simon G.
  • 181
  • 6
  • 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. – Jon Bentley Mar 25 '16 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. Mar 27 '16 at 14:30
4

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.

Ricardo
  • 103
  • 3
Sergio A. Figueroa
  • 281
  • 1
  • 10
  • 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. – Mindwin Mar 24 '16 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. – Sergio A. Figueroa Mar 24 '16 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 Mar 25 '16 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! – Dewi Morgan Mar 25 '16 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. – Sergio A. Figueroa Mar 25 '16 at 21:28
  • You can find Welsh place names in a geographical dictionary. It may not be what most people think of when they think of dictionary, but using dictionary here is not really more incorrect than anything referring to words (since when is password1 a word of any sort?) – prosfilaes Mar 25 '16 at 23:27
  • If you understand _word_ as a string of characters within your alphabet, _password1_ can be a word. Still "word book" or "known/likely password list" could be less ambiguous (although also less suitable for analogies than the term "dictionary") – Sergio A. Figueroa Mar 26 '16 at 08:51
  • "So, in general, it is hard to produce usable long passwords." Doesn't this just mean that you shouldn't use long passwords that someone *else* has generated for you (or, at least, that are published)? For example, I often generate my passwords using Apple's Password Assistant on the 'memorable' setting; it semi-randomly smooshes together several words and a soupçon of punctuation, and these are long, memorable, and (I think) reasonably strong, since there is no reason that they should appear in anyone's rainbow tables. – LSpice Mar 27 '16 at 21:21
  • If it's usable, that sounds like a sensible idea. However, usability issues are always there. How often would you be willing to type your long, secure password? Would that apply also for non technical users? (Not trying to disincentive your approach, just trying to keep a critical eye) – Sergio A. Figueroa Mar 27 '16 at 21:29
0

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

Alexey Vesnin
  • 1,565
  • 1
  • 8
  • 11
0

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"

coteyr
  • 1,506
  • 8
  • 12
0

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.

hildred
  • 449
  • 1
  • 4
  • 9
-1

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
polarathene
  • 19
  • 3
  • Most of this looks like a response to another answer and not a direct answer to the question asked. – schroeder Mar 21 '21 at 23:44
  • And then what is a direct answer is little different from the highest voted answer. – schroeder Mar 21 '21 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? – polarathene Mar 22 '21 at 02: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. – polarathene Mar 22 '21 at 03: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 Mar 22 '21 at 07:43
  • The 3rd part regarding 256-bit was the only part referencing another answer due to a lack of information and what appears to be false claims. It was on topic with the answer I had provided with insights on 128-bit, and how security doesn't realistically increase beyond the limits I detailed. If you see no value in that information, I won't debate that any further. Anyone reading these comments will be aware of the removed parts of my answer and can look at the revision history if it'd be useful to them. – polarathene Mar 22 '21 at 21:02
  • Your second part started off with "Regarding the take on limits of physics as the threshold, there was a lack of supporting sources:" That's not a part of the question. So, you *might have* something somewhere in all that that might have been helpful, but you did not write it ***as an answer***. As I said, I removed the parts that were addressing other answers. Please make sure that your answers directly address the question. – schroeder Mar 23 '21 at 00:57