Is salted MD5 or salted SHA considered secure?

Question

Is using something like bcrypt or scrypt necessary? The hashes are so much longer to store in a database. Can one get away with using salted MD5 or SHA and still be secure?

Answer 1

MD5 and SHA-1 are emphatically poor choices for storing passwords. The problem is not their collision-resistance; it's that they're designed to be extremely fast. A modern GPU can attempt upwards of billions of passwords per second when brute-forcing through a list of hashes. This can shred through every possible eight-character alphanumeric password in at most a few days; that's with just one GPU.

The advantage of bcrypt and scrypt is that they can consume arbitrarily many resources; bcrypt has configurable CPU requirements, scrypt has configurable CPU and memory requirements. By increasing these work factors, you can dramatically increase the amount of effort it takes an attacker to attempt even a single password in your database.

As to the length: it's 2014. Storage is essentially infinitely cheap. Saving 40 bytes per record is simply not an acceptable excuse for selecting known-poor password hashing algorithms. In whatever project you're working on, surely there are more worthwhile tasks to spend your limited development resources on than this.

Answer 2

There is, in fact, no such thing as "salted MD5" or "salted SHA-1". MD5 and SHA-1 are well-defined hash functions, which take as input a sequence of bits of (almost) arbitrary length, and output a sequence of bits of fixed length (128 and 160 bits, respectively). There is no salt anywhere in the definitions of MD5 and SHA-1; no password either, for that matter.

What people call "salted MD5" or "salted SHA-1" are in fact new cryptographic construction, assembling some encoding convention (to transform the password into a sequence of bits) and a salt value (another sequence of characters or bits) into one (or a few) invocations of the hash function. There are lots of possible ways to do that, and no standard. At best, we can have a family of designs which can be grouped under the generic terminology "MD5 with some salt". Cryptographically, these constructions need not be equivalent to each other; some may be quite poor.

Even assuming that your specific "salted MD5" happens not to botch things, you still get the main problem of MD5 (or SHA-1), and that is speed. Speed means that attackers can try a lot of potential passwords per second; numbers are in the billions per second (benchmarks there). If you want to "get away" with salted MD5 or SHA-1 then you need to fight that speed with more password entropy. Not password length, mind you; length is only loosely correlated with security. Adding more characters does not help; adding more characters that the attacker does not know of is what helps.

Realistically, if you must get away with salted MD5 or SHA-1, then you must go for at least 60 bits of entropy in each password. This is unrealistic: average users will not produce or remember such passwords. At best, you can consider yourself happy if your users achieve 30 bits of entropy. In other words, with salted MD5 or SHA-1, you will fall short of the required security level by a factor of one billion or so. These are poor odds; to make an analogy, this would be similar to trying to military invade the USA when your whole army consists of a single soldier armed with a baseball bat. Stallone failed. Even Chuck Norris would find that challenging.

Go read these answers:

• On password hashing: the theory and practice needed to think corectly about it.
• On entropy calculation for passwords.

And go buy a new disk ! My first actual hard disk (back in 1991) had size 40 megabytes and would have been fit to store bcrypt hashes for more than half a million of users. Is your server 23-years old hardware, and do you have more than half a million of users ? If that is the case, then I salute you for your courage, and I warmly suggest that you should go sleep in some asylum with medical assistance. Otherwise, the "hashes are so much larger" argument is, there's no nice way to say it, really stupid.

---

^{Ok, there is a sure method to get away with using salted MD5 or SHA-1. It suffices to have a server which is so uninteresting and devoid of any non-boring data that attackers don't even bother to attack it. Laziness is still the strongest force in the Universe, after all.}

Answer 3

No, you cannot get away with MD5 or SHA, and this topic has really been discussed to death.

All general-purpose hash algorithms like MD5 or SHA are extremely vulnerable to brute-force attacks, because they're designed for speed. For example, an old GPU like the HD 6990 can calculate around 10 billion MD5 hashes per second and 4 billion SHA-1 hashes per second using oclHashcat.

It's easy to see that even decent passwords will not survive such an attack. For example, searching the entire space of all passwords with 6 alphanumeric characters only takes 6 seconds if you're using MD5. And even 8 characters only take 6 hours. Adding salts doesn't change this. While salts force the attacker to go after each hash individually, this makes little difference given the performance.

When hashing passwords, you do not want speed. To the contrary, the procedure should be very expensive and slow. That's why specialized password hash algorithms like bcrypt and scrypt are needed.

Answer 4

Salting MD5 isn't good enough. MD5 isn't collision-resistant, meaning an attacker can come up with a password to match any given hash value (whether or not it's actually the "right" password). The attacker doesn't care what the value was before you hashed it, including any salting you do; they just need the final value to produce a valid password.

On the other hand, I believe most versions of SHA (at least SHA-2 and SHA-3) are still considered secure, but I don't know what the state-of-the-art is for password storage. Depending on the application, you might want to run it multiple times.

EDIT - On second thought, I'm not sure it's known to be possible to reverse MD5 to yield a particular salt if you're keeping the salt associated with the account on the server side. I'm pretty sure salted MD5 is still not recommended, though.