为了散列而隐藏盐的必要性
在工作中，我们有两个相互竞争的盐理论。 我所使用的产品使用类似用户名或电话号码的形式来加密散列。 基本上，每个用户都有所不同，但我们随时可以获得。 另一种产品为每个用户随机生成一个盐，并在用户每次更改密码时进行更改。 盐然后在数据库中加密。
我的问题是如果第二种方法真的有必要吗？ 我从纯粹的理论角度可以理解，它比第一种方法更安全，但从实用性的角度来看呢。 现在要验证用户，salt必须是未加密的并应用于登录信息。
思考过后，我从这个方法看不到真正的安全收益。 即使攻击者知道如何快速确定每个帐户的内容，但是将帐户之间的差异更改为帐户仍然会使人难以企图强制哈希算法。 这是假设密码足够强大。 （很明显，找到一组密码的正确哈希值，它们都是两位数字，比找到正确的8位密码哈希要容易得多。 我的逻辑不正确，还是我缺少某些东西？
编辑：好吧，这就是为什么我认为它加密盐真的没什么意义。 （让我知道我是否在正确的轨道上）。
对于下面的解释，我们假设密码总是8个字符，salt是5，并且所有密码都由小写字母组成（它只是使数学更容易）。
对于每个条目都有不同的盐，意味着我不能使用同一张彩虹表（实际上，如果我有足够的尺寸，我可以在技术上做到这一点），但暂且忽略它。 根据我的理解，这是盐的真正关键，因为要破解每个帐户，我必须重新发明轮子，以便为每一个人说话。 现在，如果我知道如何将正确的salt应用于密码来生成哈希，我会这样做，因为salt实际上只是扩展了哈希短语的长度/复杂度。 所以我会减少我需要产生的可能组合的数量，以便“知道”我有密码+盐，从13 ^ 26到8 ^ 26，因为我知道盐是什么。 现在，这使得它更容易，但仍然很难。
所以加密盐。 如果我知道salt是加密的，我就不会尝试解密（假设我知道它有足够的加密级别）。 我会忽略它。 回到前面的例子，我只想生成一个包含13 ^ 26所有键的更大的彩虹表，而不是试图找出解密的方法。 不知道盐会使我放慢脚步，但我认为这不会增加尝试破解盐加密的巨大任务。 这就是为什么我认为这不值得。 思考？
这里是一个链接，描述在一次暴力攻击下密码将持续多长时间：http://www.lockdown.co.uk/?pg=combi
这里的答案是问自己你真的想要保护什么？ 如果有人可以访问您的数据库，那么他们可以访问加密的盐，并且他们也可能访问您的代码。 有了这些可以解密加密的盐吗？ 如果是这样的话，无论如何加密都是无用的。 盐真的在那里，所以它是不可能形成一个彩虹表来一举破解你的整个密码数据库，如果它被打破。 从这个角度来看，只要每种盐都是独一无二的，就没有什么区别，对于每种密码都需要对您的盐或加密盐进行强力攻击。
隐藏盐是不必要的。
每个散列应该使用不同的盐。 实际上，通过从密码质量随机数生成器中获取8个或更多字节可以很容易地实现。
从我以前的回答：
Salt有助于防止预先计算的字典攻击。
假设攻击者拥有可能密码的列表。 他可以散列每一个，并将其与受害者密码的散列进行比较，并查看它是否匹配。 如果清单很大，这可能需要很长时间。 他不想在他的下一个目标上花费那么多时间，所以他将结果记录在一个“字典”中，一个散列指向其相应的输入。 如果密码列表非常长，他可以使用彩虹表等技术来节省一些空间。
但是，假设他的下一个目标淹没了他们的密码。 即使攻击者知道盐是什么，他的预先计算表也毫无价值 - 盐会改变每个密码产生的散列。 他必须将所有密码重新打散到他的列表中，并将目标盐粘贴到输入中。 每种不同的盐都需要不同的字典，如果使用了足够的盐，攻击者将无法为所有字典存储字典。 交易空间节省时间不再是一种选择; 攻击者必须回退哈希每个他想攻击的目标列表中的每个密码。
所以，没有必要保持盐的秘密。 确保攻击者没有与该特定盐对应的预先计算的字典就足够了。
在仔细考虑这一点之后，我意识到，欺骗自己认为盐可以隐藏是危险的。 尽管如此，假设盐不能被隐藏，设计系统是安全的。 我在另一个答案中提供了更详细的解释。
我对“盐”的理解是它使得破解更加困难，但它并不试图隐藏额外的数据。 如果你试图通过使盐“秘密”来获得更多的安全性，那么你真的只需要在你的加密密钥中有更多的位。
链接地址: http://www.djcxy.com/p/21539.html