bCrypt是改进与hmac的密码？

Question

鉴于：

$salt—一个伪随机生成的字符串，长度足够长

$Pepper-一个足够强的私钥，只有存储口令的数据库管理员知道

你会看到吗

###########################################################################################################

有意义地优于

$hash=bcrypt（$userpassphrase，$salt）

考虑到管理/储存$pepper和$salt的额外负担？

我的假设是，hmac不会有意义地加强生成的$hash，并且存储$pepper的负担超过了任何假定的好处。。。但我很愿意听取知情的意见。

Answer 1

将一个额外的哈希附加到一个密码扩展函数上是没有意义的，比如bcrypt；再迭代几次会更容易也更好。

“胡椒”是一种常用但有问题的做法；就我个人而言，我认为攻击者获取您的数据库但无法访问您的密钥的攻击模型是经过精心设计的，因此不值得对其进行保护，因为这样会导致实现的复杂性。

Answer 2

我不知道你想怎么用它。假设您存储$hash以稍后进行挑战响应身份验证，那么您需要将$Pepper发送给客户端，这只是另一种盐。简单地添加一个HMAC不会有太大的用处。

Answer 3

密钥散列或HMAC用于验证数据源，而不是用于密码保护。例如，如果您和我有一个共享密钥，我可以将一些数据与计算出的hmac一起发送给您，您可以使用相同的密钥检查hmac哈希是否匹配，如果匹配，您知道数据来自我，并且没有被更改。

您无法有效地在计算机上隐藏攻击者无法获取的机密密码短语，您所要做的只是增加一层模糊性。在没有共享密钥的情况下使用HMac本质上与使用SHA（$userpassphrase，$salt）相同，这非常容易计算，因此，一旦知道“secret”密码短语，就不会给密码哈希方案添加任何有意义的安全性。

bcrypt的全部目的只是为了减缓散列过程，因此攻击者需要很长时间才能为您的salt生成彩虹表。如果你想让你的密码散列方案更安全，只需增加原始散列函数的成本。在bcrypt中，您可以指定“logRounds”的数量（我想这就是他们所说的），这是执行哈希的次数。如果指定logRounds为15（默认值为10），则哈希将执行2^15=32768次，这将显著降低其速度。执行哈希所需的时间越长，攻击者破坏哈希所需的时间就越长。