Is there any benefit to *really* strong passwords?

password_one = "Z;$]bnNvY3I-Ww]R4qm7PpiE/@y9Qz$cNk{d3"
password_two = "4tjDqq])G-^u:PT~X]QBTa,XqUk[o9(p?iCw8*)*T9t\@l+^+U04m@_8CXV:E7L\R]\>N6M.0E|%Ud_f*]bN*rn^;FX7\M%5t?"


It seems to me that they are both strong. Is password_two harder to crack than password_one?

I guess this depends on what sort of hashing is involved. What if Bcrypt or sha512 are used, would there be any benefit for using password_two?

• I won't post a true answer as it wouldn't be related to cryptography. I'll just say that it's highly likely that neither of these passwords are safe or usable. Most applications won't take a password this long or this range of ASCII characters. And if they did, you'd have to save it in a text file on your desktop anyway defeating it's purpose. Hashing it becomes irrelevant. QuoteMeHappy insurance only takes 12 characters! – Paul Uszak Jun 15 '17 at 11:17
• @PaulUszak Passwords can always be stored by a password manager. The first point is valid though; some applications silently truncate the user input and others restrict the kinds of symbols that can be used. – Kevin Li Jun 15 '17 at 13:41
• @KevinLi however the characters that are not allowed in one application are sometimes required by another. – twharmon Jun 15 '17 at 13:43
• @Travis i can imagine a hilarious scenario where a web application truncates passwords to 12 characters before hashing and storing, but demands at least 1 special (!@#$%^&*()…) character. A user provides ghijklmnopqr$ (13 chars). The validating function accepts the password because it contains $, then hashes the remaining ghijklmnopqr (12 chars) and stores it as the correct password. I’ve gotten unauthorized access into a few sites with implementation problems like that. – Kevin Li Jun 15 '17 at 13:51 • @KevinLi Nope. I'm a secretary working for an international bank. My desktop is delivered to me via Citrix and locked down like a nun's drawers. How should I install myself a password manager? I just keep them on a pad at the back of the desk. – Paul Uszak Jun 15 '17 at 22:02 3 Answers I'll assume those were generated by selecting characters independently and uniformly at random, out of a set of 95 characters. Entropy is the base 2 logarithm of the number of equiprobable choices, so each character chosen independently at random contributes$\log_2(95) \approx 6.6$bits of strength to your password. So the strength of password_one is about$37 \times 6.6 = 244.2$bits. That's already stronger than any cryptographic key will ever realistically need to be—it's comparably strong to a 256-bit key. It's strong well past the point where the choice of password hashing algorithm is relevant; if people could be reliably counted on to memorize passwords this strong, we wouldn't need such algorithms. People choose terrible passwords; the often-cited XKCD password strength comic famously pegged passwords like Tr0ub4dor&3 at about 28 bits, and even that is likely much better than average. That means that your password_one is, arguably, total overkill, because: 1. Passwords need to be user-friendly. For example, they need to be convenient to type or input into one's device. 2. If your password is this crazy strong, that just means that your weak point is somewhere else, and it's likely way, way weaker than the crazy password. You're well past the point of diminishing returns. If you're just a regular Jane or Joe who is not subject of special interest by spy agencies and such, I think 80-bit(ish) strength passwords are plenty strong enough for website logins; a 12 character random ASCII character password (e.g., Z;$]bnNvY3I-) is at about this level, and much more convenient than what you're doing. For password-based encryption you could consider going up to about 128-bit strength.

• Further, many modern uses of passwords have some level of entropy stretching, that adds like perhaps $10\pm10$ bits of entropy to that of the password (with 1000 rounds of PBKDF2-HAMC-SHA-1 typical of the lower-end of the spectrum). – fgrieu Jun 16 '17 at 7:09

password_one = "Z;$]bnNvY3I-Ww]R4qm7PpiE/@y9Qz$cNk{d3"
password_two = "4tjDqq])G-^u:PT~X]QBTa,XqUk[o9(p?iCw8*)*T9t\@l+^+U04m@_8CXV:E7L\R]\>N6M.0E|%Ud_f*]bN*rn^;FX7\M%5t?"


It seems to me that they are both strong. Is password_two harder to crack than password_one?

The inherent strength of your generated password depends on the number of possible outcomes, the probability of each outcome, and—in this day and age—whether your password is on somebody’s list or not.

The kinds of symbols, the rules governing when and where each symbol can appear in your password, and the length are all things that need to be considered to determine the number of possible outcomes. From your first example:

• 94 possible symbols (10 digits, 26 uppercase letters, 26 lowercase letters, 32 special characters excluding the space character)
• 37 symbols
• 94³⁷ ≈ 1.01×10⁷³ (ten tresvigintillion) possible outcomes

If these are generated using a uniformly random source, then your password has the strength of log₂(1.01×10⁷³) ≈ 242.52 bits. Any biases in the generator decreases the strength of your password.

And if you’ve kept up-to-date on password breaches, remember that once your password is on a list, its security is as good as taping the password to the underside of your desk. And you can be sure password_one and password_two are on some list already.

Hashing

I guess this depends on what sort of hashing is involved. What if Bcrypt or sha512 are used, would there be any benefit for using password_two?

The hash algorithm can do one thing for a password: map the password to the hash algorithm’s output space.

Typically, applying a hash function will increase the time to guess and test each possible password—a form of key stretching. A single application of SHA-512 won’t stretch it appreciably, but repeated applications of it will increase the time it takes to try each guess (sha512(sha512(sha512((password)))). PBDKF2 is a function that works on that principle. The bcrypt function that you mentioned, however, is a stronger function based on repeated applications of a Blowfish-derived algorithm.

One thing that should be noted is that if your password has 243 bits of security, and your hash algorithm has a 128-bit output, then by the pigeonhole principle, your security is only 128 bits.

Finally, as noted on Wikipedia’s page on bcrypt (perma-link):

Many implementations of bcrypt truncate the password to the first 72 bytes.

An application of such an implementation of bcrypt to password_two would ignore the last 28 characters. That means these two passwords could produce identical outputs, and the software/hardware would happily accept either as correct:

4tjDqq])G-^u:PT~X]QBTa,XqUk[o9(p?iCw8*)*T9t\@l+^+U04m@_8CXV:E7L\R]\>N6M.0E|%Ud_f*]bN*rn^;FX7\M%5t?
4tjDqq])G-^u:PT~X]QBTa,XqUk[o9(p?iCw8*)*T9t\@l+^+U04m@_8CXV:E7L\R]\>N6lalalalalalalalalalalalalala


…which means in this case, there is no benefit to having the extra 28 characters! But the answer to your question is really implementation-dependent.

As they always say, beware when rolling your own security. Pitfalls abound, and it’s very easy to get wrong!

The other answers cover it well, but I think it's worthwhile to mention that this is very similar to the 128-bit vs 256-bit debate. In reality, both are very strong. While the second one may be stronger by 128 orders of magnitude, the difference in security is negligible. One will take the lifetime of our sun to break, the other will take the lifetime of the universe. Either way, it's strong enough.