什么是最好的方法来存储验证者后一个高熵秘密？

Question

这只是一个思想实验。我试图了解什么时候我们需要密码哈希函数，当他们没有带来任何好处(例如。以节省计算成本)。

我知道在存储密码验证器时会使用密码散列函数，因为密码通常具有较低的熵。那么高熵的秘密呢？用普通的现代散列算法对它们进行盐分和散列是否就足够了，还是应该仍然使用密码散列函数来增加计算时间和内存？

例如:用户使用加密安全的RNG生成一个256位的秘密，然后作为“密码”注册。它是否足够好存储一个盐和沙256哈希的盐渍密码比较，在未来？

Answer 1

这是众所周知的哈希算法选择的安全/成本平衡：

• 消耗的资源越多，对暴力攻击假设哈希被泄露了的抵抗力就越强。
• algo消耗的资源越少，服务器上可以接受的用户就越多。

当您有一个有状态的应用程序时，常见的假设是登录操作很少发生，并且花费时间没有问题。

但是，根据系统的安全要求和预期的负载，计算成本通常会被调整。

有一点是正确的:蛮力攻击的总成本是密码熵的散列算法代价的乘积。

在决定使用快速散列函数和希望使用高熵密码的问题是，您对最终用户将如何选择其密码几乎没有控制。由于键入密码通常必须足够简单，使人能够记住它们，并键入它们没有错误-我不能希望键入一个64个字符的密码没有错误.

另一种可能的选择是使用存储的令牌。由于它们不需要手工输入，大小不是问题，您可以安全地使用快速散列函数。您只希望用户能够安全地存储它们，但毕竟这是他们关心的问题。例如，这是在GitHub上使用的。作为GitHub用户，我知道我的帐户的安全性受到存储我的令牌的机器/应用程序的安全性的限制。

Answer 2

那么高熵的秘密呢？用普通的现代散列算法对它们进行盐分和散列是否就足够了，还是应该仍然使用密码散列函数来增加计算时间和内存？例如:用户使用加密安全的RNG生成一个256位的秘密，然后作为“密码”注册。它是否足够好存储一个盐和沙256哈希的盐渍密码比较，在未来？

是的，但实际上你不知道用户是怎么做的，所以你会通过密码哈希算法来运行它。

然而，对于高熵的事情，在控制生成(或者至少知道所使用的过程)时，使用安全(但快速)哈希算法的一个迭代是非常合理的，比如SHA2-256或SHA3-256。这是一种合理方法的一些例子：

• API密钥(本质上是密码，而是机器的密码，不是为了让人难忘，甚至不一定是可打印的)。
• 不透明会话令牌
• 刷新令牌(通常与JWT配对)
• 密码重置令牌(通常以十六进制或base64的形式在URL中传输)
• 密码密钥(如果您只是检查用户提供的密钥在用于一串加密/解密之前是否正确)

这样做的理由很简单。密码会得到额外的哈希，因为它们有些可预测；理论上，合理长度的密码可能是数百位熵，但在实践中却更像是几十个。使密码哈希值达到百万倍的代价，就像使密码具有另外20位熵一样，对于强制散列的困难来说是很困难的。但是:这仍然只会让你从大约40比特的熵(如果它是一个相当好的密码；如果不是的话)降低到相当于60位的成本。这仍然超过了十分之一的工作量，比蛮力强制128位值要少一倍。类似地，密码会被盐碱化，这样它们就会有唯一的散列，而你不能预先计算它们，但盐分所做的只是在密码中添加一些熵(通常是64-128位)(然后将额外的熵存储在纯文本中，这样就不会真的变得更硬了)。高熵(128+位熵)值已经比典型的密码+ 64位(甚至96位)盐具有更大的熵；碰撞是不可能发生的，而预计算实际上是不可能的，因为地球上没有足够的存储空间来保存表，也没有足够的计算来生成表。

Answer 3

这取决于其他这类秘密的质量。如果秘密是高熵的，但它是作为密码存储的，而其他秘密是典型的低熵密码，那么您应该使用像Argon2这样的普通密码哈希函数。那是因为你不想让你很容易猜到那些弱者，即使有像你所描述的那样的强者。

如果其类型的所有秘密都是高熵(也就是说，至少有128位密码安全随机性)，例如，因为您为API的用户生成了随机标记，那么您可以使用咸散列，因为强制执行在计算上是不可行的。具有强哈希函数(如SHA-2、SHA-3或BLAKE2 )的HMAC是一种很好的方法(与其他强MACs一样)。