0

I want to store my passwords using 2 different hashes (saving 2 hashes for the same password to (slightly) increase security by (almost) eliminating collisions. first question: is there enough of an upside for this in the first place since collisions are negligible anyway ? second question: what would the best hashes for this be ? do sha-1 and sha-256 have more collisions than sha-256 and some unrelated algorithm like blowfish ?

xyious
  • 1,065
  • 4
  • 13
  • 29
  • Do you need to hash or could you use encryption? E.g. http://www.php.net/manual/en/intro.mcrypt.php – Colin Jun 22 '11 at 18:45
  • 3
    use bcrypt for this. and never invent your own cryptography! – Spike Gronim Jun 22 '11 at 18:48
  • 1
    You should calculate the probability of collision of a sha256. There is about 10^80 atoms in the entire Universe. There are less chance to found a specific atom in the entire Univese thant to have two different string generating the same hash. Furthermore you should read the introduction of "The art of computer programming". There is an enlightening part about security and randomness. – yogsototh Jun 22 '11 at 18:52
  • I would like to use something that can not be decrypted, if mcrypt or bcrypt would allow me to do that i suppose that would be alright. – xyious Jun 22 '11 at 19:06

2 Answers2

0

If I understand you correct you want to store the hashed password two times with two different hashing algorithms in your database yes? Simply use two hashalgorithms producing a different length and there is no chance of collision between the two different hashes at all.

For instance sha1 and md5 provide different lengths of output.

hoppa
  • 3,011
  • 18
  • 21
  • i really don't like md5 because of how easy it is to calculate collisions, which then makes the whole idea less secure rather than more secure since you can try passwords that give collisions with the md5 hash to figure out the real password (given that you have it, but i don't want to rely on my code/db never getting out). – xyious Jun 22 '11 at 18:57
  • It was an example, simply use another hashing algorithm producing a different output length. But in general I agree with Jesse, it is absolutely not true that it is easy, or even to be expected, that you will find collisions in your database. – hoppa Jun 22 '11 at 19:03
-2

I would recommend using a sha1 and not worrying about collisions. The likelyhood of a sha1 collision is 10^-45 (as explained here Probability of SHA1 collisions), so unless you will have billions of users, it will never be an issue.

Community
  • 1
  • 1
Jesse
  • 10,370
  • 10
  • 62
  • 81
  • -1 SHA-x should *not* be used for passwords. –  Feb 11 '13 at 01:46
  • Hey, @pst thanks for the input - however, a year ago SHA1 for passwords was still pretty common. I realize a bunch of articles have just come out about cracking them, but instead of finding and downvoting out of date answers, how about posting a helpful answer on a more secure alternative? You're not helping OP (or anyone else) without providing a smarter alternative. – Jesse Feb 11 '13 at 20:39
  • It was still bad information a year ago. Down-votes can be changed after corrections (or appropriate warnings) are added. Finding better techniques is hardly a hard task, and I gave a free implicit question: ["Why is SHA-1 not suitable for passwords?"](http://stackoverflow.com/questions/2772014/is-sha-1-secure-for-password-storage) (that question is the first google hit to the previous question). Also, see the [first linked](http://stackoverflow.com/questions/401656/secure-hash-and-salt-for-php-passwords?lq=1) for instance. It is a false assertion that it is my job to explain the problems. –  Feb 11 '13 at 21:10