我听说盐的唯一目的是防止彩虹表攻击,但肯定它必须比这更有价值?它不会阻止基于字典的攻击吗?那么暴力强迫,盐会在那里有用吗?你能解释一下原因吗?
其次,假设我有一个算法,它使用了微量的时间,一个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)
彩虹表是一种优化方法,可用于字典攻击和暴力攻击。
正确使用的盐使得预计算对于字典和暴力攻击是不可行的。由于彩虹表是一种预计算优化,因此它是盐析所扼杀的优化之一。
你的第二个例子实际上只是一个较长的盐,有一些较低的熵部分。令人担心的是,你将“随机数”与“盐”区分开来,因为盐应该是随机数。