Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question

4 Answers 4

up vote 15 down vote accepted

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.

share|improve this answer
    
A beautiful quote from that article is "It’s a really common misconception — including among security people — that the problem here is using SHA-1. It would not have mattered at all if they had used SHA-512, they would be no better off at all." which, of course, couldn't be further from the truth. The author reasons that because you can crack it once it's offline, it's all the same which is, of course, incorrect. –  corsiKa Jul 7 at 21:13

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).

share|improve this answer

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.

share|improve this answer
    
Wouldn't the salt or the hash pattern replace the original password so doing it 100000 times make any input a valid password? (kind of a complicated /2. Eventually it will become one or zero, except a bit pattern) –  acidzombie24 Jun 17 '12 at 3:17
4  
@acidzombie24 No. This isn't how the hash function works. –  Oleksi Jun 17 '12 at 3:21

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.

share|improve this answer
    
Wouldn't the salt or the hash pattern replace the original password so doing it 100000 times make any input a valid password? (kind of a complicated /2. Eventually it will become one or zero, except a bit pattern) –  acidzombie24 Jun 17 '12 at 3:17
2  
No, read up on how hashing works. –  Terry Chia Jun 17 '12 at 3:23
    
@acidzombie24, this is true for some hash functions (e. g. the sum of the digits in a number). Cryptographic hash functions, however, are supposed to be resistant. –  Hendrik Brummermann Jun 19 '12 at 7:29

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.