关于散列盐的综合信息 [英] Comprehensive information about hash salts

问题描述

有关盐和最佳实践的很多问题，但是大多数人只是回答关于它们的非常具体的问题。我有几个问题，彼此矛盾。

There are a lot of questions about salts and best practices, however most of them simply answer very specific questions about them. I have several questions which feed into one another.

假设数据库受到威胁，每个用户的盐阻止使用通用的彩虹表来破解密码。将必须为具有唯一盐的每个用户生成单独的彩虹表以获得其密码。这将是一个耗时的过程，这使得盐有效。

Assuming a database is compromised a per user salt prevents the use of generic rainbow tables to crack passwords. A separate rainbow table would have to be generated for each and every user who had a unique salt in order to obtain their password. This would be a time consuming process which is what makes salts effective. This does not help a tremendous amount against dictionary or brute force attacks.

这会导致一些问题：

1. 虽然盐不是通过隐身的安全性将盐放在单独的表中还更安全吗？


2. 如果第二个硬编码的应用程序宽盐添加了大量的量，那么即使的安全？

1. Although a salt is not meant to be security through obscurity wouldn't it still be more secure to place salts in a separate table? That way even if the 'users' table was to become compromised the salts would not.
2. Would having a 2nd hard-coded application wide salt add a tremendous amount of security? This way even if the database is compromised, the actual application would also have to be compromised or both the salts and hashes would be completely useless.
3. What is the best length for a salt? Obviously the longer the better, however with larger numbers of users database size does become an issue, so what would be the minimum length for an effective salt be?
4. Is using a 3rd party source for a "true random salt" (random.org, random.irb.hr) really needed? I understand using a salt based off of server time is "guessable" to some extent however taking a random sub-string of a sha1'd random string seems like an effective salt method.

提前谢谢。

推荐答案

1. 如果一个黑客可以访问你的数据库系统，你就是fsckd。您的系统必须能够访问这两个表才能运行，因此将一个已经入侵系统的黑客隐藏的可能性几乎为零。

1. If a hacker has access to your database system, you're fsckd. Your system has to have access to both tables to run, so the likelihood of "hiding" one from a hacker who's already compromised the system is nearly zero. Not remotely worth the extra complexity, in my opinion.

为每个密码添加一个nonce并不是一个很好的帮助

Having a "nonce" added (in addition) to a salt for each password is not a great help, but doesn't really hurt anything either.

即使16位的盐通常足以使密码破解不可行，如果正确的话。我可能会使用64或128位，为什么不？

Even 16 bits of salt is typically enough to make password cracking infeasible, if done correctly. I would probably use 64 or 128 bits, why not?

你应该使用一个好的随机源，但它不需要是完美的。如果攻击者以某种方式看到随机值，则他们可能能够找到一种方法来预测下一个随机值，但是在创建密码时它们必须这样做，并且只能获得一个密码。 / p>

You should use a "good" source of randomness, but it doesn't need to be perfect. If the random values are somehow visible to an attacker, then they may be able to find a way to predict the next random value, but they would have to do this when the password is created and it would only get them that one password.

总之，您需要每个用户的salt和一个好的散列函数。 MD5是可怕的，并且SHA-1不再是好。你应该使用像bcrypt这样的系统来强制攻击者在每个散列上花费相当一部分的时间。每次密码检查可能没有什么大不了的0.1s，但它对任何种类的暴力破解都是毁灭性的。

In short, you need per-user salt and a good hashing function. MD5 is terrible, and SHA-1 is no longer "good". You should be using a system like bcrypt to force an attacker to spend a considerable fraction of a second on each hash. 0.1s per password check is probably no big deal to you, but it's devastating to any kind of brute-force cracking.

这是对实施密码安全方案：

This is required reading for anyone implementing a password security scheme:

http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables -what-you-need-to-know-about-s.html

这篇关于关于散列盐的综合信息的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！