盐如何防止字典攻击？
可能的重复：
盐的用途是什么？
我刚刚读了一点关于盐的使用，我一直在阅读的示例给出了在散列之前向密码添加盐以防止字典攻击的方法。
然而，我真的不明白这有什么帮助 - 如果攻击者可以访问密码的哈希值（就像他们在我读过的示例中所做的那样），他们很可能也可以访问盐。 因此，在运行字典以查看它是否与哈希匹配之前，攻击者不能在字典中的每个项目之前和之后添加盐吗？所以他们必须多次遍历字典，这似乎并没有多大的保护增强？
Possible Duplicate:
What is the purpose of salt?
I've just been reading up a bit about the use of salts, and the example I've been reading gives that of adding a salt to a password before hashing to protect against a dictionary attack.
However I don't really see how that helps - if the attacker has access to the hash of the password (as they do in the example I've been reading) they most likely they will also have access to the salt.
Therefore can't an attacker just prepend and postpend the salt to each item in a dictionary before running through the dictionary to see if it matches the hash? So they have to iterate through the dictionary more than once, that's doesn't seem much of a protection enhancement?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
字典攻击是一种攻击，其中攻击者获取大量密码（可能按可能性/概率排序），并对每个密码应用算法，检查结果。
在使用加盐密码的情况下，如果攻击者拥有盐（通常假设的情况），则此类攻击仍然是可能的（并且成本不会显着增加）：也只需在算法中输入盐即可。
盐所防范的是彩虹表。 彩虹表是一个包含明文对（例如密码）和相应哈希值的表，按哈希值排序。这样的表允许在给定哈希值的情况下简单地查找密码。
生成彩虹表是一个成本高昂的步骤（取决于用作输入的字典的大小），但随后您可以使用它而无需任何成本来查找所需数量的密码。
由于盐可以防止这种情况，因为您现在需要为每种盐准备一个单独的表。即使使用简单的 Unix crypt 的 2 字母 salt，这也已经是 3,844 的因数了。现代密码哈希算法使用更大的盐（例如 bcrypt 使用 128 位盐，其系数为 2128。）
为了防止字典攻击，您也将使用 <慢速哈希算法，而不是简单的 MD5 或 SHA1/SHA2 等快速算法。 Bcrypt就是这样一种算法（具有可配置的工作因子），同一作者后来提出了scrypt（它不仅需要大量时间，而且需要大量内存，而攻击者通常没有那么多的处理能力）。
A dictionary attack is an attack where the attacker takes a large list of passwords, possibly ordered by likelyhood/probability, and applies the algorithm for each of it, checking the result.
In case of a salted password, such an attack is still possible (and not significantly costlier), if the attacker has the salt (what is normally assumed): Simply input the salt in your algorithm, too.
What a salt protect against, is a rainbow table. A rainbow table is a table containing pairs of plaintext (e.g. passwords) and the corresponding hashes, ordered by hash. Such a table allows a simple lookup of the password, given the hash.
Producing a rainbow table is a costly step (depending on the size of the dictionary used as input), but then you can use it without any cost later to lookup as many passwords as wanted.
As salt protects against this, since you now would need a separate table for each salt. Even with the simple Unix crypt's 2-letter salt, this already is a factor of 3,844. Modern password hash algorithms use a much larger salt (for example bcrypt uses a 128-bit salt, which gives a factor of 2128.)
To protect against dictionary attacks, too, you'll use a slow hash algorithm instead of a fast one like simple MD5 or SHA1/SHA2. Bcrypt is such an algorithm (with a configurable work factor), and the same author later proposed scrypt (which not only takes much time, but also needs lots of memory, which attackers often don't have as much as processing power).
1- 你不能使用彩虹表来破解哈希值
2- 如果两个用户具有相同的密码，则加盐后的哈希值会不同（因此很难捕获常见密码）
1- You can't use rainbow tables to crack the hashes
2- If two users have the same password the hash would be different if salted (so it's harder to catch common passwords)
实际上盐并不能防止字典攻击。它具有以下优点：
Actually a salt doesn't protect against dictionary attack. It has the following benefits:
通过增加密码文件中可能答案的数量，它确实增加了他们必须做的工作。
进行字典攻击的一种方法是扫描密码文件。如果没有盐并且您看到“DFGE$%$%£TEW”，那么您知道密码是“PASSWORD”。添加盐意味着您必须使用更大的字典，其中包含“PASSWORD”的所有值以及所有可能的盐，或者您必须花费精力读取盐并进行加密，这会减慢您的速度。这不再是简单的搜索。
在多个用户选择相同密码的情况下，Salt 也会有所帮助。特别是在过去，当所有用户都可以读取密码文件时，如果其他用户具有与您相同的密码，或者与您知道的密码相同，则这一点并不明显。
It does increase the work they have to do by increasing the amount of possible answers in the password file.
One means of doing a dictionary attack is to scan the password file. If there is no salt and you see "DFGE$%$%£TEW" then you know the password is "PASSWORD". Adding salt means you'll have to use either a much larger dictionary containing all the values for "PASSWORD" with all possible salts, or you have to spend the effort to read the salt and do the encryption which slows you down. It's no longer a simple search.
Salt also helps in situations where more than one user chooses the same password. Especially in the old days when the password file was readable by all users, it makes it not obvious if another user has the same password as you, or the same password as one you know.
字典攻击基于字典中的单词。通过添加随机盐，字典中就不再有单词了。因此，基于字典单词的密码哈希表对于破解密码没有帮助。
Dictionary attacks are based on words from the dictionary. By adding a random salt, you no longer have dictionary words. Thus a password hash table based on dictionary words will not be helpful in cracking a password.
每个盐值都需要不同的字典，因此每个不使用盐的数据库都可以使用相同的字典进行攻击。
无需任何盐，攻击者就可以使用现成的盐
预先计算的字典，其中有很多。
如果您的整个数据库只有一种盐，那么他们需要
创建一个特定于您的数据库的字典。
如果每个用户记录都有自己的盐，那么现在他们需要创建 1
每个用户的字典。
Each salt value requires a different dictionary, so every database that doesn't use a salt can be attacked with the same dictionary.
Without any salt an attacker can just use an off-the-shelf
pre-computed dictionary, of which there are plenty.
If you have one salt for your entire database then they need to
create a dictionary specific to your database.
If each user record had it's own salt, now they need to create 1
dictionary per user.