Password hashing: Is this a way to avoid collisions?

I was thinking about using 2 keys for hashing each user password, obtaining 2 different hashes.开发者_运维百科 This way, it would be (almost?) impossible to find a password that works, other than the actual password.

Is that right? Is it worth it?

---

An important rule to learn is "never try to invent your own cryptography". You are just wasting time at best and introducing security holes at worst.

If you are unsure whether you are an exception to this rule, then you are not an exception to this rule.

The designers of cryptographic hashes already worried about collisions so you do not have to. Just pick one (SHA-256 is a fine choice) and focus your efforts on the rest of your application.

---

You might use SHA256 as a hashing algorithm instead. No collisions were found to date, and it's highly unlikely to see any collisions on passwords in the future.

---

You could just use a longer hash. SHA-512, for example, is 512 bits, and (assuming it's uniform) far, far less likely to clash as SHA-256. But personally, I wouldn't worry about it. Most passwords themselves are less than 32 bytes (256 bits), and so should have an extremely low probability of clashing with SHA-256.