Then you’d make the same mistake yet again: SHA-3 was never intended for password hashing and is completely unsuitable for this purpose, because it provides no brute-force resistance whatsoever. Trying around 3 billion passwords per second is not a problem on high-end consumer hardware. This rate can be further increased by using specialized hardware (ASICs) or cloud services.
Cryptography is an exact science. Every tool has a very specific purpose and must be used in a very specific way. If you pick an algorithm just because it sounds good, things will go wrong.
So again: If you use anything other than the four algorithms mentioned above, you’ll end up with no security at all. And that’s not a joke.
It is strongly advised to use the recommended password hashing function, which is handily available at all time using password_hash/password_verify. If you use this library and send in PASSWORD_DEFAULT as your wanted algorithm, PHP will automatically use what is considered the most secure algo.
At the moment this algorithm is Bcrypt, which is preferred as as it has been through some extensive testing and abuse, ti’s designed to withstand asic/gpu cracking, it properly generates good salts, etc.
Even with the most recommended algo you can still do it wrong. With Bcrypt you can adjust the cost factor, which is an exponential work load value. Remember password hashing is supposed to be slow (it’s one of the only defences we have against brute forcing), so pick a cost that gives you a fair trade off between UX, server load, and security. 12-15 seems to be normal these days, which should take .1 - .25 seconds.
And for the love of god, please use a verified library instead of implementing your own version of it. Getting the algo, salt, etc correct is not something you should be fiddling witch, unless you’re one of the few who actually make these things (you probably aren’t).
To extend on this - the reason is that you’d want to use Bcrypt is that
SHAx aren’t password hashing algorithms. They are designed to give you a “unique” hash value for a given set of data. This is actually something we don’t want, as that would lead to every user having the same password getting the same hash. Also, these data checksum hashes are something you want to generate fast - and fast is something we definitely don’t want when talking about passwords. You could argue it’s just to implement salting to the SHAx hashing to make it secure, but doing this correctly isn’t as easy as just appending a “random” value. And as always, don’t roll your own crypto.
PBKDF2 just isn’t quite there, it’s so good it can be used, but the possibility to crack it on asic/gpu’s is pretty bad.
Bcrypt is what’s considered the best we have, it’s specifically designed to not “work” on GPUs, it’s tested and proven, and has good support on various systems/languages/libraries.
Scrypt is not considered battle tested enough.
Argon2 just won the password hashing competition, and may be great but definitely needs some time in the field before we know its safe.
In tech new isn’t always better, especially security we want to rigorously test before using.
