3

I am new here, and have poked around the site looking for an overview of which hash algorithm to use on the web and why.

It seems to be the consensus that SHA-256 or other SHA-2 family algorithms are the best because they do not have the collisions that MD5 and older hash techniques have. I'm wondering if SHA-2 family techniques are less supported on the web because of other reasons besides security, such as ease of implementation or speed of execution.

On a website that is already protected by the encryption of an SSL certificate via TLS/HTTPS the data (i.e. a password) is already being encrypted anyway (putting aside the recent issues with Heartbleed). So perhaps more priority has been given to algorithms that are easier to implement rather than more secure? It still seems sketchy to use MD5 on the web, i.e. for password hashing.

Which hashing algorithm is best for the web and why?

JHS
  • 152
  • 1
  • 7
  • 2
    Keep in mind that hashing was never developed for security, but rather verification and integrity monitoring. While you are correct that MD5 is inherently collision ridden, all hashes will eventually be brute-forced. What are you planning on using this hash for? – PTW-105 Apr 22 '14 at 23:21
  • 2
    @PTW-105 All hashes will be brute-forced? That's quite the ridiculous claim. There are `115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936` unique 256-bit hashes. Reverse this sha-2 (256 bit -- I was nice even chose the weaker one) `f80aca950ca3eabc7ce99d2be088257dec01c9c4f7c841854702acdbb07c76b1`. I'll give you $1000 if you or anyone else can do it. – dr jimbob Apr 23 '14 at 01:26
  • @drjimbob - Eventually. Some day we will have computational systems that will make it feasible to brute-force that hash. It may not be possible today, maybe not tomorrow, but eventually. – PTW-105 Apr 23 '14 at 01:53
  • @PTW-105 - The smallest unit of time that makes sense to even think is the [Planck time (10^-44 seconds)](http://en.wikipedia.org/wiki/Planck_time) this is about 1000000000000000000000000000 times smaller than the smallest unit of time we've ever measured. It's only been about ~10^61 Planck time old since the big bang is about [~10^61](http://www.wolframalpha.com/input/?i=Time+since+big+bang+in+Planck+Time). Note there are about 3 million billion more SHA-256 hashes than Planck times since the big bang. (So hash ever Planck time since the big bang would have 1 in 3 million billion chance.) – dr jimbob Apr 23 '14 at 02:40
  • @PTW-105 and SHA-512 will be 2^256 times harder than SHA-256. (That is SHA-512, you have to try for high entropy information would have to try about `13,407,807,929,942,597,099,574,024,998,205,846,127,479,365,820,592,393,377,723,561,443,721,764,030,073,546,976,801,874,298,166,903,427,690,031,858,186,486,050,853,753,882,811,946,569,946,433,649,006,084,096` different hashes). – dr jimbob Apr 23 '14 at 02:45
  • @drjimbob - While I agree that it will not be in our lifetime, SHA-256 has a chance to be broken at some point. Im.not going to argue with you about how long it will take, but I do understand that it is not practical at this moment in time. Meanwhile, I will notate that you are a fan of and are quite knowledgable on SHA-256 and SHA-512. – PTW-105 Apr 23 '14 at 03:15
  • Thank you for the interesting discussion. To answer your question @PTW-105, I am actually doing a presentation on password hashing for a class at my University, so there are no security concerns here besides theoretical ones. – JHS Apr 23 '14 at 17:23

2 Answers2

6

Which algorithm is best depends on what you're using it for. If you're trying to spot random data corruption, for example, a blindingly-fast algorithm like CRC-32 is ideal. On the other hand, if you're trying to secure password hashes, you want an inherently slow algorithm like bcrypt. For protecting data transfers against malicious tampering, you want a fast, cryptographically-secure algorithm such as SHA-256. And finally, if you need to interoperate with someone else's software, you use whatever hash function they're expecting.

Mark
  • 34,390
  • 9
  • 85
  • 134
  • Thank you very much! This is a good overview. I was confused before about how the speed of a hash factored into its usability. (Now I understand that slower ones are better for passwords because they are less feasible for a hacker to break.) – JHS Apr 23 '14 at 17:28
3

When in doubt, use SHA-256. This is the default answer for situations where you need a generic hash function; for specialized cases such that hashing passwords, the situation is different: you don't want to use MD5 or SHA-1 or SHA-2 or SHA-3 for passwords, but something like bcrypt.

SSL is a deployed standard with a long history, and typically uses SHA-1. This is fine. Though SHA-1 has some theoretical weaknesses against collisions, collisions are not a problem in the way SHA-1 is used in SSL (it is used as part of HMAC, which works more on preimage resistance than collisions). SHA-256 can be used with SSL, but only with the most recent standard (TLS 1.2) which is still not deployed everywhere.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Very interesting. Thank you. I will have to read more on Blowfish/bcrypt and SSL/TLS. – JHS Apr 23 '14 at 17:32
  • For that matter, MD5 is still resistant to preimage attacks. It's just that since practical collision attacks are known, everyone expects it's only a matter of time until preimage attacks are found. – Mark Apr 23 '14 at 19:35