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

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.

• There is no exact answer since we don't know the power of all supercomputers, some here Jan 22 '21 at 8:33
• I’m voting to close this question because this question cannot be answered. We can make an estimate, however, we are sure that it cannot reach $2^{250}$ so use a password with a strength 250-bit, bip39 or dicewire has password mechanisms that you can calculate the strength. Jan 22 '21 at 8:36
• Why the 250-bit value? Jan 22 '21 at 10:20
• crypto.stackexchange.com/q/1145/18298 Jan 22 '21 at 10:20

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

• I think you swapped quantum and classical in your last sentence. Jan 22 '21 at 23:19
• @SAIPeregrinuss yeah something went wrong there, let me think of a better way to word it. . Jan 23 '21 at 12:03

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.