为哈希隐藏盐的必要性

在工作中,我们有两种相互竞争的盐理论.我工作的产品使用类似用户名或电话号码来加密哈希值.基本上每个用户都有不同的东西,但我们可以随时使用.另一个产品为每个用户随机生成一个salt,并在每次用户更改密码时更改.然后在数据库中加密盐.

My question is if the second approach is really necessary? I can understand from a purely theoretical perspective that it is more secure than the first approach, but what about from a practicality point of view. Right now to authenticate a user, the salt must be unencrypted and applied to the login information.

在考虑之后,我只是没有从这种方法中看到真正的安全性收益.将盐从帐户更改为帐户,即使攻击者知道如何快速确定每个帐户的内容,仍然会使某人尝试强制执行散列算法变得非常困难.这是基于密码足够强的假设.(显然,找到一组密码的正确哈希值,它们都是两位数,比找到8位密码的正确哈希值要容易得多).我的逻辑是不正确的,还是我缺少的东西？

编辑:好的,所以这就是为什么我认为加密盐真的没有意义.(lemme知道我是否在正确的轨道上).

对于以下说明,我们假设密码总是8个字符,盐是5,所有密码都由小写字母组成(它只是使数学更容易).

Having a different salt for each entry means that I can't use the same rainbow table (actually technically I could if I had one of sufficient size, but let's ignore that for the moment). This is the real key to the salt from what I understand, because to crack every account I have to reinvent the wheel so to speak for each one. Now if I know how to apply the correct salt to a password to generate the hash, I'd do it because a salt really just extends the length/complexity of the hashed phrase. So I would be cutting the number of possible combinations I would need to generate to "know" I have the password + salt from 13^26 to 8^26 because I know what the salt is. Now that makes it easier, but still really hard.

所以加密盐.如果我知道salt是加密的,我首先不会尝试解密(假设我知道它有足够的加密级别).我会忽略它.不要试图弄清楚如何解密它,回到前面的例子,我只会生成一个更大的彩虹表,其中包含13 ^ 26的所有键.不知道盐肯定会减慢我的速度,但我认为它不会增加尝试首先破解盐加密的巨大任务.这就是为什么我不认为这是值得的.思考？

这是一个链接,描述密码在暴力攻击下会持续多长时间:http://www.lockdown.co.uk/？ pg = combi

1> erickson..：

---

隐藏盐是不必要的.

每个哈希都应该使用不同的盐.实际上,通过从加密质量随机数生成器获取8个或更多字节很容易实现.

从我以前的答案:

Salt有助于阻止预先计算的字典攻击.

假设攻击者有可能的密码列表.他可以散列每个并将其与受害者密码的哈希值进行比较,看看它是否匹配.如果列表很大,这可能需要很长时间.他不希望在下一个目标上花费那么多时间,因此他将结果记录在"字典"中,其中哈希指向其相应的输入.如果密码列表非常长,他可以使用像彩虹表这样的技术来节省一些空间.

但是,假设他的下一个目标是他们的密码.即使攻击者知道盐是什么,他的预计算表也毫无价值 - 盐会改变每个密码产生的哈希值.他必须重新哈希他列表中的所有密码,将目标的盐粘贴到输入上.每种不同的盐都需要不同的字典,如果使用了足够的盐,攻击者就没有足够的空间来存储所有字典.交易空间以节省时间不再是一种选择; 对于每个要攻击的目标,攻击者必须回退到列表中的每个密码.

因此,没有必要保持盐的秘密.确保攻击者没有与该特定盐相对应的预先计算的字典就足够了.

---

在考虑了这个之后,我意识到愚弄自己认为盐可以被隐藏是危险的.假设盐不能被隐藏,并且尽管如此设计系统是安全的,这样做要好得多.我在另一个答案中提供了更详细的解释.

---

@The Rook - 不,你错误地解释了这个问题.它指的是使用可预测的盐.它没有说保持盐的秘密.事实上,如果不使用另一个秘密,你就无法真正保密盐......在这种情况下,你为什么不把第二个秘密用作盐？使用用户名作为盐是不好的,因为它可能是多个系统共享相同的用户名,这使得为特定的盐构建表更有价值.随机盐是最好的,但它们**不需要保密.

---

@Ultratrunks是的,我已经使用术语"预先计算的字典攻击"澄清了我对这个主题的一些答案.比Rainbow表更通用,它指的是允许使用其散列作为键来反向查找明文的任何结构.无论你选择哪个术语,我都明确地解释了盐旨在打败彩虹表和类似的机制.你应该总是假设攻击者知道盐.如果可以保密,则不需要哈希密码.

2> tloach..：

---

这里的答案是问问自己你真正想要保护的是什么？如果有人可以访问您的数据库,那么他们可以访问加密的salt,并且他们也可以访问您的代码.他们可以解密加密盐吗？如果是这样,那么无论如何加密都是无用的.盐实际上是为了制作它所以如果它被打破,就不可能形成彩虹表来一次性破解你的整个密码数据库.从这个角度来看,只要每种盐都是独一无二的,就没有区别,你的盐或加密盐就需要对每个密码单独进行蛮力攻击.