How long would it take all of the supercomputers or cloud computing on Earth to bruteforce a significantly long password?

Question

I was arguing with a colleague who thinks that SHA256 (password + 64 character static salt) is "insecure." My argument is that nothing in cryptography is "secure," it's all a sliding scale, and the amount of time it would take to bruteforce such a combination would be so long (I'm thinking over 30 years) that for all intents and purposes it is "secure." His argument is that because SHA256 hashes are so quick to generate, you can crack something like this using all of the computers on Earth quite easily, and as such, it's "insecure."

I agree that using something like Bcrypt is "more secure," but I wouldn't consider the above "insecure" because of the difficulty in cracking such a thing. If we factor in Moore's law, which argument is correct? And how about if we change that 64-character salt to a 128-character salt?

I feel like this is an argument about semantics, but it annoys me that someone can have such a black-and-white perspective that "this is insecure (SHA256 pass + insanely long salt), but this is secure (Bcrypt)". I understand that something like Bcrypt is obviously preferred and "more secure," and I could see the argument that the other approach is "less secure," but to say one is "secure" and the other is "insecure" is to me a fallacy.

Answer 1

A salt is supposed to be publicly available, for instance it needs to be stored in a DB next to the password hash. In that case the time it takes to recover the password is just a brute force or dictionary for the password. If the salt is static then rainbow tables may be used as well for any attack. Now if the password has an entropy of 256 bits then this is obviously not a problem. Actual passwords however only have about 42 bits of entropy on average, and this is why bcrypt is often needed to provide some additional security.

It is of course also possible to use a 256 bit pepper, which is a salt value that is kept secret. In that case "cracking" the hash will require both the password and the pepper. We cannot do that even with quantum computers because the energy requirements would be too high (cracking > 128 bit security against classical computers or > 256 bit against quantum computers is completely infeasible and forever will be).

Answer 2

SHA256 (password + 64 character static salt) is "insecure".

Indeed, it's insecure under standard hypothesis of password hashing, corresponding to leak of the password hashes:

• The SHA-256 hash is known (at least in part; 8 out of the 32 bytes will do).
• The salt is known in full (typically it's stored along the password hashes, because it's needed when a user logins; if it's static and in the code, leak of the code and mild reverse engineering can reveal it; that's also a standard and realistic assumption).
• The password is memorable or (including and) chosen by a user.

By this estimate, a fair password like correct horse battery staple has 44 bits of entropy. Make that 50 for good measure. Testing $2^{50}$ among the more plausible passwords would take less than a day on a single machine with a good GPU†.

With "all of the supercomputers or cloud computing on Earth" carefully organized (this is the hard part), a password with 80 bits of entropy (24 decimal digits, or 13 random characters among 71) is within reach.

Problem is: password hashing must be made purposely slow (iterative) and if at all possible memory hard, but SHA-256 is designed to be fast and use little memory, thus next to the worse possible for a password hash. Use Argon2, or if not possible scrypt, or if not possible bcrypt. If forced at gunpoint, settle for PBKDF2 with a decent number of iterations, it's still much better than the question's scheme.

---

† Based on conservative extrapolation of this hashcat benchmark listing 164 GH/s for a similar MD5-based scheme, translating to $2^{50}$ hashes in less than 2 hours.

Answer 3

There is a physical upper limit for any computation. There is a theoretical minimum amount of energy that is needed to change any system from one state to another state. (Today's computers need a lot more energy than the theoretical minimum). There is a theoretical upper bound for energy spent, and that is the total mass of the universe, completely converted to energy.

It turns out that the theoretical upper limit for energy isn't enough to perform 2^256 state changes, so any calculation requiring that many state changes is physically impossible.

Yes, it is entirely feasible to create keys long enough that a decryption with todays best known methods is physically impossible.

Answer 4

I was having an argument with a colleague, who thinks that SHA256(password + 64 character long static salt) is "insecure". My argument is that nothing in cryptography is "secure..."

But isn't that 100% true? There is no proof that SHAx is information theoretically secure, just as there is no proof that AES hasn't been broken by state actors. Or their code implementations. Just because low paid academics can't invert these primitives, doesn't mean by any stretch of the imagination that they haven't been by professional intelligence operatives working for decades within an annual ~$B80 budget.

I suppose that the real issue here is that no modern code breaking requires brute force. We just skirt the algorithm and crib/invert it through mathematics like differential do-da and re-linearisation that's not published for 25 years due to NOBUS policy. See Zerodium. So a good question but cryptographically moot because thinking goes: they don't need to.

It's just that the answer is not what most here expect.

---

1. You're going to laugh at this answer, but before you draw breath please read the NOBUS link and what President Obama said about it.

2. This answer excludes direct action against the cryptographer which results in code break within days.