Password hashes should run md5 thousands of time: really?

Question

I skimmed through How Companies Can Beef Up Password Security and I thought that several assertions were completely wrong, in particular:

1. Cryptographic hash (like md5) with salt are bad.
2. It isn't uncommon to break/crack unix shadow files.
3. To make a password hash I should run it over md5 or whatever hundreds or thousands of times.

The article suggests that salted hashes are too easy to break and you'd want to select a password hash because its computationally longer to check passwords so you can not do as many per second.

I think doing 3 is bad for security and 1 is in reality the best option. What do you guys think?

Answer 1

Cryptographic hash (like md5) with salt are bad.

It is not sufficient anymore. The traditional cryptographic hash functions are designed for documents and therefore they are optimized for speed.

But speed is exactly what we don't want for password hashes. Modern graphic cards can do 2,000,000,000 SHA1 or MD5 hashes per second. So brute forcing a 6 character password takes less than 10 minutes.

It isn't uncommon to break/crack unix shadow files.

That's true for the old hashes used in them.

To make a password hash I should run it over md5 or whatever hundreds or thousands of times.

While this is am improvement over just using a quick hash function ones, it is not sufficient.

You should use one of the hash crypt algorithms (except for md5crypt): sha256crypt, sha512crypt, bcrypt or scrypt. Those are algorithm that are designed to be relatively slow and not easily implementable on graphic cards to gain a performance boost.

Those algorithm do more than just using the output of one round as input for the next round. The rules of what to use as input vary based on the iteration counter (See the linked specifications). Modern unix operating system use sha512crypt.

scrypt goes one step further than the other algorithms because in addition to scalable CPU usage, scrypt uses a lot of memory. The idea is to make hardware implementations of password crackers a lot more expensive. Such hardware usually has access to up to 1KB of fast memory, but the default parameters of scrypt require 16MB.

Answer 2

Cryptographic hash (like md5) with salt are bad.

I didn't read the article, but this could be read in one of two ways:

1. MD5, even when salted is bad.
2. Salted hashes are bad.

In response to the first one, yes, this is true. MD5 has been proven insecure, and is too fast to be a secure hashing function anyways. Don't use MD5.

As for the second, it's completely wrong. Always salt your hash's. This helps prevent against rainbow table attacks.

It isn't uncommon to break/crack unix shadow files.

This is true, most people choose insecure passwords that are quite easy to break. End of story. The classic security tool for doing this is John the Ripper. Even shadow files that use modern hashes often use algorithms that are too fast to really provide much protection (see below).

To make a password hash I should run it over md5 or whatever hundreds or thousands of times.

This used to be true. The reason for doing this is to make it much slower per password attempt (since you have to run the hashing algorithm a lot). Even with a modern hash like SHA2, it's still often so fast that brute forcing a poorly chosen password can take a matter of days, or even hours.

Modern digest algorithms take this into account, and are designed to be computationally, or memory intensive. Common examples include bcrypt which includes a salt and is designed to be computationally expensive. A newer algorithm, scrypt, has been getting a bit of attention recently for also being memory intensive (making GPU cracking that much more difficult).

Answer 3

Why do you think 3 is bad for security? Really what you should be doing is using something like bcrypt to hash your passwords to avoid all this mess.

Bcrypt combines those properties. It hashes the password using a salt many times over to create a slow and secure hash function that produces cryptographically secure hashes.

Answer 4

1 is a must. Salts are very important in ensuring that passwords cannot be easily cracked just by comparing it against a rainbow table.

Why do you consider 3 bad? It is a technique known as key stretching. And it considerably increases the time and computational power needed to crack passwords.

As for 2, I would say it isn't uncommon to crack common/bad passwords stored in the shadow file. Good passwords (highly random, alphanumeric etc.) should still be relatively safe.