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.

Scenario: a database of hashed and and salted passwords, including salts for each password, is stolen by a malicious user. Passwords are 6-10 chars long and chosen by non-technical users.

Can this malicious user crack these passwords?

My understanding is that MD5 and SHA-1 are not safe anymore as GPU assisted password recovery tools can calculate billions of these hashes per second per GPU.

What about SHA-256 or SHA-512? Are they safe currently? What about in a few years?

share|improve this question
1  
Lifetimes of cryptographic hash functions is very interesting. A variation I've heard of is to always use two hashing algorithms. That way you can always deprecate one as soon as it's insecure, and you get a time window to migrate all data instances. –  l0b0 Jun 22 '11 at 11:18
    
@l0b0 depending on the use case, that can be detrimental to the overall security of the cryptosystem. E.g. using a weak hash as input to a strong hash, will still leave the strong hash with very low entropy (if this matter for your situation). –  AviD Jun 27 '11 at 20:52
add comment

migrated from stackoverflow.com Jun 21 '11 at 21:44

This question came from our site for professional and enthusiast programmers.

4 Answers

up vote 30 down vote accepted

The question doesn't state how many rounds of hashing are performed. And the whole answer hinges on that point.

All hash functions are unsafe if you use only one iteration. The hash function, whether it is SHA-1, or one of the SHA-2 family, should be repeated thousands of times. I would consider 10,000 iterations the minimum, and 100,000 iterations is not unreasonable, given the low cost of powerful hardware.

Short passwords are also unsafe. 8 characters should be the minimum, even for low value targets (because users reuse the same password for multiple applications).

With a $150 graphics card, you can perform 680 million SHA-1 hash computations per second. If you use only one round of hashing, all 6-character passwords can be tested in a little over 15 minutes (that's assuming all 94 printable ASCII characters are used). Each additional character multiplies the time by 94, so 7 characters requires one day, 8 characters requires 103 days on this setup. Remember, this scenario is a 14-year-old using his GPU, not an organized criminal with real money.

Now consider the effect of performing multiple iterations. If 1,000 iterations of hashing are performed, the 6-character password space takes almost 12 days instead of 15 minutes. A 7-character space takes 3 years. If 20,000 iterations are used, those numbers go up to 8 months and 60 years, respectively. At this point, even short passwords cannot be exhaustively searched; the attacker has to fall back to a dictionary of "most likely" passwords.

share|improve this answer
1  
@Seppo --- thousands of times, not hundreds. Even the original PKCS #5 recommend at least 1000 iterations. You should be thinking about tens of thousands. The good thing is, you should be able to update existing password hashes without forcing users to pick new passwords. Obviously if bad guys already have the poorly hashed passwords, it's too late (think about backups, etc.). But if they don't yet, it's not too late to fix things. –  erickson Jun 21 '11 at 16:31
1  
You can also use bcrypt or similar tools which take some type of work factor to slow down the hashing process for you. codahale.com/how-to-safely-store-a-password –  Jon Jun 21 '11 at 18:42
1  
The iteration count of PBKDF2 is the work factor for a hashing solution. Bcrypt is really not so exotic. They both achieve slowness with a tunable key derivation routine. One key difference is that bcrypt actually uses the derived key to encrypt a well-known plain text, and store the resulting cipher text, while most hashing solutions just store the derived key directly. However, I think both approaches are robust. –  erickson Jun 21 '11 at 19:04
1  
Succinctly, the generic cryptographic hash algorithms are designed to be fast. Protecting a password requires a slow cryptographic hash algorithm. A fast cryptographic hash algorithm, iterated 2^16 times, becomes a slow cryptographic hash algorithm. Then add in other requirements such as salts, etc. –  yfeldblum Jun 21 '11 at 23:00
2  
"Each additional charcter multiplies the time by 94, [...] 7 characters requires one day, 8 characters requires 7 years" - shouldn't 8 characters require 94 days? –  Nick Johnson Jun 22 '11 at 0:52
show 9 more comments

The purpose of salt is to protect from attacks using ranbow table. If the attacker knows the salt, he/she can calculate a new rainbow table based on the salt value.

So the short answer would be yes. Salt being stolen will allow attacker to be able to use rainbow table attack against these credentials (although the attacker has to build a unique rainbow table first).

The long answer would be depending on how complex these passwords are. If the user uses a simple password (stackoverflow), then salt being stolen would have a bigger impact on the password. If the user uses a complex password ($TACK0verflow), then the salt being stolen would have a much smaller impact (as they are unlikely to appear in any rainbow table).

share|improve this answer
8  
This is incorrect and reflects a misunderstanding of rainbow tables and salts. –  GregS Jun 21 '11 at 14:23
5  
@GregS: one of the great things about our community is that if you have additional or different information you can provide it simply by posting an answer... –  Chris Lively Jun 21 '11 at 15:27
9  
The only reason to compute a rainbow table is to reuse the effort to compute the table. The cost of computing the table is slightly more than the cost of trying all the possible passwords that the table covers. A salt eliminates the benefit of the rainbow table because every password entry has a different salt. –  GregS Jun 21 '11 at 23:37
2  
Essentially, salts protect the file as a whole, but they do not protect one password. Without salt, you break the whole file in one pass over all possible passwords. With varying salts, you break one password in a pass over all possibile passwords. Oh, and salts protect against someone noticing that another crypt'd string is the same as theirs on the off chance that they both used the same password. –  dannysauer Jun 22 '11 at 23:04
2  
@Yuliy, if that is how Jim is using the phrase "rainbow table attack", he is using it wrong. That phrase already has an accepted meaning, and it is not the same as "brute-force search". –  D.W. Jun 27 '11 at 17:29
show 4 more comments

If the attacker knows the salt, he/she can calculate a new rainbow table based on the salt value.

It depends on the algorithm being used. According to Coda Hale, MD5 and the SHA family of hashing algorithms are general purpose and meant for speed. In short, he goes on to conclude that these are not sufficient for preventing dictionary attacks and that bcrypt is the way to go, as there is more setup time involved in cracking passwords, drastically slowing down an attacker. Here's another interesting article on bcrypt.

What about SHA-256 or SHA-512? Are they safe currently? What about in a few years?

Be warned, there are two sides to this argument. There is the bcrypt side and the SHA-256 and up side. If you believe those in the SHA family side, then I believe you'll be safe for more than a few years with SHA-256, even some argue that SHA-1 with a salt is still good enough, but if you want to be safe then I would stick to SHA-256. There is a forum that also mentions that MD5 still has 5-10 years to be proven "sufficiently unreliable." Unfortunately I can't post the links to it, because I already reached my maximum of two.

Personally, I'm using SHA-256 with a salt, but I'll definitely have to read more into bcrypt and re-evaluate. Hopefully, this helps. This is a type of question you can easily spend countless hours researching, but nonetheless interesting.

share|improve this answer
    
Here is the forum that mentions MD5 still has 5-10 years. Also, the argument that SHA-1 is still good enough. –  SantosLHalper Jun 21 '11 at 15:27
1  
Yay, for loopholes! –  SantosLHalper Jun 21 '11 at 15:28
add comment

The salt may be considered public practically by definition.

As for what hash to use and how "safe" it is, I would stick with the recommendations NIST makes for U.S. government agencies. As the Wikipedia article says:

SHA-1 is being retired for most government uses; the U.S. National Institute of Standards and Technology says, "Federal agencies should stop using SHA-1 for...applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010"

You can speculate about how safe or unsafe various algorithms are, but why bother when you have a spec the U.S. government considers good enough for its own use?

[edit]

By the way, your question appears to reflect a misunderstanding about how these analyses are performed. There is much more to a hash function than its number of bits.

Brute-forcing a 160-bit hash like SHA-1 requires 2^160 effort; that is simply not going to happen, no matter how many "GPUs" you throw at it. In fact it probably will not happen in the lifetime of the universe. (True, brute-forcing a collision requires "only" 2^80 effort. But it also requires 2^80 storage. Good luck with that.)

The reason MD5 and SHA-1 are considered "possibly unsafe" is that weaknesses have been discovered in each algorithm that might reduce the work way, way below the brute-force effort. The reason for switching to a newer algorithm (like SHA-2) is to avoid those known weaknesses; the reason for using 256 bits is to provide some buffer against unknown weaknesses. It has nothing to do with "GPUs"; to resist brute-force attacks, 160 bits is plenty.

Similar statements hold for all cryptography, by the way.

Now, it is impossible to overstate how much more the folks at NSA know about this stuff than you or I do. They make recommendations for U.S. government agencies and U.S. industry via NIST. So unless your adversary is itself a major world government, the NIST recommendations are more than sufficient. Ignore any self-proclaimed "experts" who try to tell you otherwise; NSA is better at what it does than you can possibly imagine.

If your adversary is a major world government, nobody at SO is qualified to help you. And you have much bigger problems than which hash function to use.

[edit 2]

Of course I am assuming you are already using this function as part of a standard password hashing scheme, like PKCS#5 (also known as "PBKDF2"), and your question was purely about what hash function to use.

PBKDF2 recommends a minimum of 1000 iterations, but you can choose whatever you want. The attacker's brute-force effort goes up linearly with that number, so 10000 iterations vs. 1000 means it will take them 10 times longer to brute-force each password.

share|improve this answer
1  
If I can calculate hashes really quickly what stops me from going through all the possible password combinations that are 8 or less characters long? –  Seppo Erviälä Jun 21 '11 at 16:01
    
Character distribution in passwords isn't random either: r-bloggers.com/character-occurrence-in-passwords –  Seppo Erviälä Jun 21 '11 at 16:01
1  
@Seppo: The salt. You would have to repeat the search for each password you want to crack. Also note that I am assuming you are using a standard like PKCS#5, which adds a bunch of iterations to make brute-force attacks difficult even for one password. Basically, my advice is to stick to standard algorithms and modes of operation. –  Nemo Jun 21 '11 at 16:03
2  
Brute-forcing a 160-bit secret, where each bits is a separate random variable uniformly distributed across {0,1}, takes 2^160 time. Brute-forcing user passwords that have been hashed, where many passwords are 6 letters long, use no capitalization, numerals, or special characters, and are found in the English dictionary, takes significantly less time. –  yfeldblum Jun 21 '11 at 23:05
add comment

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.