我听说盐的唯一目的是防止彩虹表攻击，但肯定它必须比这更有价值？它不会阻止基于字典的攻击吗？那么暴力强迫，盐会在那里有用吗？你能解释一下原因吗？
其次，假设我有一个算法，它使用了微量的时间，一个128字符的盐和一个介于10亿到100亿之间的随机数，并将它们混合在一起。这会提供很高的安全性吗？因为即使攻击者知道其中一个细节，在我看来，计算其余部分仍然在计算上是不可行的。这是对的吗？
谢谢，
本
编辑：为了澄清，攻击者无法访问散列算法，因此他们不会向系统发送任何信息。它们只有散列，它们必须弄清楚它是如何编译的。当然，即使他们知道哈希是如何产生的，试图用长盐来强制所有组合也会让它变得不现实吗？
此外，哈希不是用户的密码或用户名，它只是用于身份验证的随机字符集。因此，不需要存储salt和随机数，只需要存储结果。在这种情况下，上述系统（如下面的代码所示）是一个很好的系统，可以防止攻击者真实地猜测用户的哈希值是什么？
$salt = "some random characters I made up";
hash('sha256', microtime(true).$salt.mt_rand(1000,9999));
我知道只有1000-9999而不是上面提到的数十亿。
再次感谢。
答案 0 :(得分：5)
不 - 它只能防止彩虹表攻击。攻击者需要为每个密码条目构建彩虹表。因为盐添加了一个lil spice，可以区分密码哈希和其他所有密码哈希。
基于字典和强制攻击在这里基本上是相同的。 Salting并不会阻止这些，因为您的验证算法类似于
plain-text-passwd = 'secret provided by user'
salt = getSalt(username) //looks the salt value up in database based on the users username
hash-password-in-db = getPassword(username) // looks up hashed password bassed on users username
if(hash(plain-text-passwd + salt) == hash-password-in-db) //if true, password is correct
对于基于字典和强制攻击的攻击，plain-text-passwd的值被用户发送垃圾邮件，而用户又会使用盐进行哈希处理。因此，腌制无效
其次，假设我有一个算法...
这是毫无意义的，您需要将所有这些信息存储在用户信息表中，其中5个字符的salt值用于相同的目的。
答案 1 :(得分：3)
彩虹表是一种优化方法，可用于字典攻击和暴力攻击。
正确使用的盐使得预计算对于字典和暴力攻击是不可行的。由于彩虹表是一种预计算优化，因此它是盐析所扼杀的优化之一。
你的第二个例子实际上只是一个较长的盐，有一些较低的熵部分。令人担心的是，你将“随机数”与“盐”区分开来，因为盐应该是随机数。