1
$\begingroup$

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.

$\endgroup$
4
  • 1
    $\begingroup$ There is no exact answer since we don't know the power of all supercomputers, some here $\endgroup$
    – kelalaka
    Commented Jan 22, 2021 at 8:33
  • 3
    $\begingroup$ 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. $\endgroup$
    – kelalaka
    Commented Jan 22, 2021 at 8:36
  • $\begingroup$ Why the 250-bit value? $\endgroup$ Commented Jan 22, 2021 at 10:20
  • $\begingroup$ crypto.stackexchange.com/q/1145/18298 $\endgroup$
    – kelalaka
    Commented Jan 22, 2021 at 10:20

4 Answers 4

6
$\begingroup$

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

$\endgroup$
2
  • $\begingroup$ I think you swapped quantum and classical in your last sentence. $\endgroup$ Commented Jan 22, 2021 at 23:19
  • $\begingroup$ @SAIPeregrinuss yeah something went wrong there, let me think of a better way to word it. . $\endgroup$
    – Maarten Bodewes
    Commented Jan 23, 2021 at 12:03
0
$\begingroup$

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.

$\endgroup$
-1
$\begingroup$

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.

$\endgroup$
1
  • $\begingroup$ Actually, I'm pretty sure there is enough total mass in the universe that, when converted to energy, to perform $2^{256}$ state changes. Now, if we consider a considerably more limited adversary, say, one which is limited to the amount of energy produced by our sun in a century, you would be correct... $\endgroup$
    – poncho
    Commented Feb 9, 2023 at 11:44
-3
$\begingroup$

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.

$\endgroup$
6
  • $\begingroup$ How does the one-time pad relate to hashing a password? $\endgroup$
    – Modal Nest
    Commented Jan 23, 2021 at 10:20
  • $\begingroup$ But one is a hash function? And the other doesn't really exist! I'm not sure what you mean by colleague or my question. $\endgroup$
    – Modal Nest
    Commented Jan 23, 2021 at 13:38
  • $\begingroup$ @ModalNest I'm simply referring to "argument is that nothing in cryptography is 'secure,'" in the original question. Hash functions and one time pads are members of the cryptography set. SHAx isn't provably secure, whilst OTPs are. But that was just a throwaway comment in the conclusion of my answer. $\endgroup$
    – Paul Uszak
    Commented Jan 23, 2021 at 14:36
  • 3
    $\begingroup$ Fair enough. I see the edit. It's a bit of a terminological question I suppose. I think its unusual to define secure so strictly, and to define everything else as insecure. You can easily switch it round and request proof of insecurity, which in this case would not be forthcoming. $\endgroup$
    – Modal Nest
    Commented Jan 23, 2021 at 14:57
  • $\begingroup$ There is no proof that SHAx is information theoretically secure – So? $\endgroup$
    – forest
    Commented Jan 23, 2021 at 22:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.