用hmac'd密码改进了bcrypt吗？

Question

下式给出：

$ salt - 伪随机生成的足够长度的字符串

$ pepper - 一个足够强大的私钥，只有存储密码的数据库管理员知道

你会看到

吗？

$ hash = bcrypt（hmac（$ userpassphrase，$ pepper），$ salt）

有意义地优于

$ hash = bcrypt（$ userpassphrase，$ salt）

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

我的假设是，hmac没有显着增强产生的$ hash，并且存储$ pepper的负担超过任何所谓的好处......但我希望听到明智的意见。

Answer 1

键控哈希值或HMac用于验证数据源，而不用于密码保护。例如，如果你和我有一个共享密钥，我可以发送一些数据和计算的hmac，你可以使用相同的密钥来检查hmac哈希是否匹配，如果是，你知道数据来自我，并没有被改变。

你无法有效隐藏攻击者无法访问的机器上的秘密密码短语，你所做的只是增加一层默默无闻。在没有共享密钥的情况下使用HMac与执行SHA（$ userpassphrase，$ salt）基本相同，这很容易计算，因此一旦“秘密”不会为您的密码散列方案添加任何有意义的安全性“密码已知。

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

Answer 2

我不确定你想怎么用它。假设您存储$ hash以便稍后进行质询 - 响应身份验证，那么您需要将$ pepper送到客户端，它只是另一种盐。只需添加HMAC就没有多大用处。

Answer 3

没有必要在像bcrypt这样的密码扩展函数上添加额外的哈希值;再次迭代它会更容易也更好。

'胡椒'是一种常用但有问题的做法;我个人认为攻击者获取你的数据库但不能访问你的秘密密钥的攻击模型是充分的设计，以防止它们不值得实现的实现复杂性。