据我了解，盐使相同的密码哈希值不同。 然而，盐通常存储在与密码数据库。 所以我们可以说我是攻击者，这里是如何我可能会使用（在这个例子中笔记我不写出来为简洁起见128个散列或盐）对盐字典攻击：
user_pw = 'blowfish'
Given:
email = 'blah@blah.com'
hash = '1234567890'
salt = '0987654321'
function attack(){
for each(word in dictionary)
md5( word * salt ) == hash ? cracked_one(email, word)
}
我明白这可以防止黑客使用彩虹表...但似乎并没有阻止字典攻击。 我想你可以添加别的东西对哈希算法，但与安全，我们必须假设攻击的方法是已知的。
如此看来，腌制防止黑客找出其中的密码很可能是词典的密码（那些多个用户有），防止彩虹攻击...但不能防止字典攻击。
这是一个正确的分析？ 为更好的安全性有什么建议？
谢谢！
盐不能防止字典攻击，只是预先计算好的字典攻击。 特别是，它可防止彩虹表（ http://en.wikipedia.org/wiki/Rainbow_table ），也保证了破解一个用户的密码不会自动让你破解谁共享该密码的任何用户。
我联系到文中提到的一些方法来提高在盐腌incudling重点加强（ http://en.wikipedia.org/wiki/Key_strengthening ）。
没有什么能够阻止从只是猜测密码的攻击者。
盐只是使其难以通过迫使攻击者散列每个用户（实际上，每盐）的基础上字典。
为了提高安全性，可调散列函数是你最好的选择。 杀青的时候，每哈希起来，在任何硬件上的攻击者很可能已经使可用字典攻击是不切实际的。
基本上， 阅读本 。
这是正确的。 如果有人拿到了密码材料，字典攻击将是有效的。
为了防止这种情况：
/etc/shadow ）只有root用户可读。 无盐，攻击者可以在他dictionnary生成的每一个字哈希然后对你的密码列表运行新dictionnary
随着盐，每个密码散列与随机字符串所以即使与现有散列dictionnary知识，他还是要重新创建一个包含盐用于在数据库中每一个不同的盐新的散列dictionnary。
试想彩虹表的dictionnaries表作为一个子集（小部分）。 虽然彩虹表可包含数十亿个条目，dictionnaries含有“已知单词”，顶多所以也许有几百万的条目。
为什么彩虹表无法针对盐的原因是再创作的过程是重新计算的“百亿项”，而dictionnary袭击仍然是“几百万个条目的”。 盐只有几个街区预计算值
你的逻辑是合理的，但在现实中，有足够的计算能力和时间，没有针对字典/蛮力攻击没有任何保护。
