14
$\begingroup$

My friend in the software industry came to me with one of his "dumb boss" war stories. This particular time, his (non-technical but eager to learn) manager came to him and told him to, in the new app he was developing, not store SHA2(password + salt), but SHA2(password) + SHA3(password) (both 256-bit). The boss claims that this "doubles security", because:

  • "nobody has a rainbow table for [this scheme]"

  • "salting is insecure" (no elaboration)

  • "SHA3 is better" (this app does not, in any way, need post-quantum forward secrecy)

  • "it'll slow a hacker down" (I guess?)

In my mind, this is pointless at best, and actively harmful at worst, since a hacker could just attack whatever portion of the hash he prefers. Is there any possible benefit?

$\endgroup$
5
  • 19
    $\begingroup$ I assume it's replaced $\operatorname{SHA-2}(\mathsf{password}\mathbin\|\mathsf{salt})$ with $\operatorname{SHA-2}(\mathsf{password})\mathbin\|\operatorname{SHA-3}(\mathsf{password})$. This is a terrible idea. That attackers have a rainbow table for this scheme or not is irrelevant: it's enough to have a rainbow table for either $\operatorname{SHA-2}$ or $\operatorname{SHA-3}$ to break the new scheme (that is, find a common password from the hash). The original scheme was safe from rainbow tables, thanks to the salt. Use $\operatorname{Argon2}(\mathsf{password},\mathsf{salt},…)$ $\endgroup$
    – fgrieu
    Feb 1 at 14:18
  • 20
    $\begingroup$ Obligatory warning: SHA2(password + salt) is totally inadequate for password hashing, because leaked hashes can be brute-forced way too quickly. You need a dedicated password hash that is deliberately slow (and ideally also memory-hard). Decent candidates include PBKDF2, bcrypt, scrypt, argon2. $\endgroup$
    – marcelm
    Feb 2 at 9:57
  • 3
    $\begingroup$ @marcelm: PBKDF2-HMAC-SHA-x is much better than SHA-2, but I disagree that it reaches the "decent" threshold. Problem is GPUs, FPGAs or ASICs are orders of magnitude faster than the typical software implementation, which severely limits the stretching achievable in practice. Further, 10000 rounds is still common; or even the silly 1000 in RFC 2898 that reportedly is still used by WinZip's AES crypto. $\endgroup$
    – fgrieu
    Feb 2 at 10:51
  • 6
    $\begingroup$ Did they concatenate the hashes instead of XOR-ing? $\endgroup$
    – Nat
    Feb 2 at 14:36
  • 4
    $\begingroup$ There's a reason ""Don't roll your own crypto" is a well known reply, as the answers below corroborate. $\endgroup$
    – simpleuser
    Feb 4 at 1:35

5 Answers 5

35
$\begingroup$
  • "nobody has a rainbow table for [this scheme]"

Well, this is a huge claim so needs justification. Building a rainbow table is not hard. Once you are a target, the table will be ready. For example crackstation claims to have it. So once the attackers have access to the table of SHA2(password) + SHA3(password) they could use the existing rainbow table to extract the password from one of the hashes. That is: the security is equal to one hash not two. They have more freedom, too, since they can attack whatever part of the hashing is suitable for them.

  • "salting is insecure" (no elaboration)

Salt is public, so it doesn't add to security. This is known by design. It helps to kill rainbow tables. Nobody is going to build a rainbow table for a single target - salt forces to be a single target. Instead of building a rainbow table just search, easier.

  • "SHA3 is better" (this app does not, in any way, need post-quantum forward secrecy)

SHA3 is better than what? Any cryptographic secure hash function with output size > 256 bits is secure against classical and post-quantum.

The approaches are wrong, old, and bad! We don't use SHAx for password hashing (at least not directly). We prefer specially designed password hashing algorithms like PBKDF2, Bcrypt, Scrypt, Argon2, Balloon.

  • "it'll slow a hacker down" (I guess?)

It can be a little, but at most double. Consider a correct approach, Argon2, for example:

  • one can set iteration to reduce searching, take 1M then they will slow as 1M
  • one can set memory hardness, which requires a bunch of memory to kill ASIC/GPU/FPGA
  • require many CPU threads to kill the parallelization of the attacker

Additionally:

  • Is there any possible benefit?

In normal user scenarios, No!

$\endgroup$
7
  • 2
    $\begingroup$ "Building a rainbow table is not hard"; actually, I believe that there are prebuilt rainbow tables against SHA2 (and with the proposed scheme, you can recover SHA2(password), and then use the rainbow table) $\endgroup$
    – poncho
    Feb 1 at 14:12
  • 2
    $\begingroup$ If this answer also addressed the "since a hacker could just attack whatever portion of the hash he prefers" part of the question, it would be perfect ;) $\endgroup$
    – marcelm
    Feb 2 at 10:08
  • 1
    $\begingroup$ @marcelm done. Thanks. $\endgroup$
    – kelalaka
    Feb 2 at 10:11
  • 4
    $\begingroup$ "We prefer specially designed password hashing algorithms like PBKDF2, Brcypt, Scrypt, Argon2, Balloon," - this is why this is the correct answer. The boss betrays his ignorance not through combining 2 SHA hashes, but by using SHA at all for this purpose. $\endgroup$
    – Tom
    Feb 2 at 14:48
  • 4
    $\begingroup$ @Vaelus the cost of the rainbow table will be bigger than the cost of a single search. That was the point there. If you have multiple targets, the obvious choice is to build the table where applicable. $\endgroup$
    – kelalaka
    Feb 2 at 16:17
7
$\begingroup$

Is there any possible benefit?

The only possible benefit I can see would be if someone picked an enormous password (one so long that there are over $2^{256}$ plausible passwords of that length). In that case, an attacker with a preimage attack against one of the hash functions couldn't get a plausible password (because it'd have to be a preimage to both hashes).

Yes, calling it a strength feels like an overstatement; however it is a 'benefit' (even if only in a very strange situation...). This might be the sort of thing your boss was thinking about intuitively, however it is missing some more immediate security concerns...

$\endgroup$
1
  • 1
    $\begingroup$ I'm betting that the boss would not think that, especially given the other statements. You would think about that poncho, but unless the boss is a cryptographer himself of some stature, nah. (and in designing a system I bet you would think that hey, that's nice, just to immediately dismiss it as impractical) $\endgroup$
    – Maarten Bodewes
    Feb 3 at 17:25
7
$\begingroup$

SHA2(password) + SHA3(password)

If by this you mean a concatenation of the two hashes, this actually makes it easier to break.

The attacker only needs to have either SHA2 or SHA3 rainbow table available. They can just take the half of the hash that matches their table.

Remember that there is no need to search through all possible hash values. Instead the attacker just searches through all common passwords, and once they get a hit on either hash, they know the password was correct.

$\endgroup$
4
$\begingroup$

Whenever you do something that is not standard, you risk that your implementation is broken. Either your scheme is broken on its own, or your implementation allows an attack on a scheme that would be on its own very fine.

You really need a much better argument than”I think this is a good idea” to implement a new scheme. You need some serious security professionals to check it out. And of course properly implemented security is unbreakable. You don’t need anything more secure.

$\endgroup$
4
  • $\begingroup$ Can this be quantified? I'd have thought that the combination of two known algorithms would actually reduce robustness... so if the robustness of the two algorithms is M and N respectively the combined robustness is significantly smaller than either M*N or M+N. $\endgroup$ Feb 2 at 8:12
  • 4
    $\begingroup$ @MarkMorganLloyd - It depends how you combine them and in which context. For example, if this "boss" wanted SHA2(SHA3(password)) and not a concatenation, that would force the attacker to build a special rainbow table instead of using a prebuilt one for SHA2 only. Or, for a less artificial example, 3DES was essentially a combination of DES and... DES; and some keying options made the combination stronger than DES, others didn't. "Random" combinations often reduce strength, because "random" engineering rarely works well. $\endgroup$ Feb 2 at 10:55
  • 2
    $\begingroup$ @JirkaHanika I broadly agree that something like SHA2(SHA3()) might possibly be useful, but I am extremely wary of any attempt at performing bitwise or trivial arithmetic operations (as implied by OP's use of || and +) because of the risk that unexpected patterns might appear. I forget who it was- Knuth?- who found that multiple RNGs combined together resulted in a weak sequence, and coined the aphorism "Random numbers are too important to be left to chance". $\endgroup$ Feb 2 at 12:08
  • 1
    $\begingroup$ @MarkMorganLloyd - From the context, their use of the plus sign meant concatenation. $\endgroup$ Feb 2 at 14:40
1
$\begingroup$

Others have already pointed out that raw hashing is totally unsuitable for password security. But even if you're using a hash normally in an otherwise acceptable way, hashing using two different hash functions and then concatenating the results together does not lead to more security, as demonstrated by Joux in CRYPTO 2004.

Abstract. ... we prove that concatenating the results of several iterated hash functions in order to build a larger one does not yield a secure construction.

$\endgroup$

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.