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?
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.
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.
{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.
Commented
Jun 21, 2011 at 23:05
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).
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.
