14

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?

kelalaka
  • 49,797
  • 12
  • 123
  • 211
squinged
  • 143
  • 1
  • 7

5 Answers5

35
  • "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!

kelalaka
  • 49,797
  • 12
  • 123
  • 211
8

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.

jpa
  • 711
  • 3
  • 6
7

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

poncho
  • 154,064
  • 12
  • 239
  • 382
4

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.

gnasher729
  • 1,350
  • 7
  • 9
1

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.

djao
  • 796
  • 9
  • 11