盐长度与总哈希长度之比

Salt Length To Total Hash Length Ratio

我正在使用 KeyDerivation.Pbkdf2 生成密码哈希，我想知道与 Pbkdf2 输出的总哈希长度相比，关于盐长度的一般建议是什么。

在下面的实现中，我使用的是 HMACSHA512，并假设 salt 是 512 位，hashBitLength 也是 512 位。

KeyDerivation.Pbkdf2(password, salt, KeyDerivationPrf.HMACSHA512, iterationCount, hashBitLength / 8);

我看过一个使用 HMACSHA256 的示例，但它的盐设置为 128 位，总哈希位长度为 256。 为什么要采用这种方法？

我读到 512 位可能有点矫枉过正，但就存储而言，它与我无关（不过我不确定性能会受到怎样的影响，我还没有测量过）。

salt 的长度是否应与生成的整体哈希值相同。 应该是一半吗？ 还是应该超过某个阈值但低于总长度？

我的直觉告诉我这样做是正确的（可能除了 512 位之外），因为我怀疑我正在获得最大熵，但我不是密码学家。

有人可以为我澄清一下吗？

确实不需要那么大，但让我们了解一下为什么。盐的用途是：

  1. 如果两个人的密码相同，那么'hashed'结果应该不一样。
  2. 预防rainbow table attacks.

第一点可以通过简单地使用计数器来实现——至少可以防止来自您自己的数据库的重复，但它可能无法防止您数据库中密码的哈希值与您的密码的哈希值相同在别人的数据库中使用相同的密码。这就把我们带到了第二点。

如果简单地使用一个从零开始的计数器，那么可以根据它构建彩虹 table。盐越大，彩虹 table 就必须越大才有机会发挥作用。这些 table 随着 salt 的大小呈指数增长，因此您的 salt 实际上不必那么大就可以排除这种攻击。

很难准确指出最小大小，但我可以向您保证 128 位绰绰有余。作为一名安全代码审计员，我个人肯定不会对 64 位的 salt 提出问题。

关于这个主题的安全建议的一个大问题是从来没有人分析过它——相反，你只是从自称是专家的人那里得到盲目的建议。我在 password processing 上写了一篇论文来说明这一点。具体请参阅第 3 节，了解我对盐的咆哮。

备注：要完全排除彩虹 table，请不要使用计数器。相反，选择你的盐'large enough'（如上所述）并以一种不可预测的table方式。