1

I'm creating a password storage system for a web server I'm building for fun.

Would it be more secure for me to use both SHA2 and SHA3 for hashing, and then store them in a database? If I use both algos, then I would be able to detect whether or not someone tried to send a SHA2 collision (however unlikely that may be), as the SHA3 hash would be wrong.

But is SHA2/SHA3 so secure that this whole endeavor is entirely pointless?

Michael
  • 155
  • 1
  • 5
  • 2
    don't use plain hashing for password storage. **PLEASE NEVER DO THIS!** Rather go for scrypt, bcrypt or PBKDF2. That being said collisions aren't your concern with passwords but rather second preimages and preimage attacks, which aren't even feasible for MD5/SHA-1/SHA-2/SHA-3 – SEJPM May 22 '15 at 21:06
  • 1
    I think you want to employ SHA-2 or SHA-3 at the same time or, even more precisely, in the same protocol. I would strongly suggest not *implementing* them at the same time as they are vastly different constructs :P – Maarten Bodewes May 22 '15 at 23:25

1 Answers1

3

You are doing it wrong, and thinking it wrong. The problem with password hashing is not, and never has been, about collisions. The main problems with password hashing are speed (hash functions are too fast) and parallelism (a hash function is always the same as itself).

There is a lot of theory on password hashing. As an introduction, read this answer. The simple one-line summary is: use bcrypt.

Making anything better (i.e. more secure) than bcrypt is hard (some people are trying, and do it the right way: with an open competition, public research, and years of effort). However, making something which is much worse than bcrypt is very easy, and a lot of people achieve just that seemingly effortlessly. By your scheme with a combination of SHA-2 and SHA-3, you would be on the right track to add one more person on the depressingly long list of people who felt that creativity was a good thing in cryptography, and paid dearly for it.

(None of this says anything about SHA-2 or SHA-3 as generic hash functions. But, despite the names, hashing and password hashing are in fact very distinct activities, do not have the same requirements, and should not use the same algorithms.)

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • Why do you recommend bcrypt over scrypt, as the answer clearly states "no scrypt before 2014" - and we live in 2015, even more scrypt has survived 6 years of cryptanalysis and a successor (yescrypt) is finalist in PHC. The only known vulnerabilities are cache-timing (hard to exploit) and a TMTO attack but it's still better than bcrypt IMO. – SEJPM May 23 '15 at 19:47
  • 1
    PHC exists precisely because scrypt cannot be considered to be the one-and-only answer to such questions. In fact, scrypt was initially designed to support full hard disk encryption: at password hashing time, several seconds of CPU, and gigabytes or RAM, can be devoted to a single hashing operation. For a server that authenticates clients, the conditions are different, and forces a use of scrypt with other parameters (much less CPU and RAM usage) and it is unclear whether this yields a better bargain than bcrypt. – Tom Leek May 25 '15 at 19:47