Ste*_*bob 4 c# security passwords hash pbkdf2
我正在使用 KeyDerivation.Pbkdf2 来生成密码哈希，我想知道与 Pbkdf2 输出的整体哈希长度相比，关于盐长度的一般建议是什么。
在下面的实现中，我使用 HMACSHA512，并假设 salt 是 512 位，并且 hashBitLength 也是 512 位。
KeyDerivation.Pbkdf2(password, salt, KeyDerivationPrf.HMACSHA512, iterationCount, hashBitLength / 8);
我看过一个使用 HMACSHA256 的示例，但它的盐值设置为 128 位，整体哈希位长度设置为 256。为什么要采用这种方法？
我读过 512 位可能有点过头了，但就存储而言，我不关心它（我不确定性能如何受到影响，我还没有测量过）。
盐的长度是否应与整体生成的哈希长度相同。应该是一半吗？或者它应该是高于某个阈值并低于总长度的任何东西？
我的直觉说我这样做的方式是正确的（除了 512 位），因为我怀疑我正在获得最大熵，但我不是密码学家。
有人可以帮我澄清一下吗？
它真的不需要那么大，但让我们了解为什么。盐的目的是：
第一点可以通过简单地使用计数器来完成 - 至少可以防止您自己的数据库中的重复项，但它可能不会阻止您数据库中密码的散列与其他人的相同密码的散列相同数据库。这就把我们带到了第二点。
如果一个人简单地使用一个从零开始的计数器，那么人们可以根据它构建一个彩虹表。盐越大，彩虹台就必须越大，才有机会发挥作用。这些表随着盐的大小呈指数增长，所以你的盐真的不需要那么大来排除这种攻击。
很难准确指出最小大小，但我可以向您保证 128 位绰绰有余。我个人，作为安全代码审计员，肯定不会用 64 位的盐提出问题。
关于这个主题的安全建议的一个大问题是没有人分析过它——相反，你只是从自称是专家的人那里得到盲目的建议。我写了一篇关于密码处理的论文，正是为了这一点。具体请参阅第 3 节，了解我对盐的咆哮。
备注：完全排除彩虹表，不要使用计数器。相反，选择“足够大”的盐（如上所述）并且以不可预测的方式。