给定：
$salt - 一个足够长的伪随机生成的字符串
$pepper - 一个足够强大的私钥，只有存储密码短语的数据库管理员知道
你会看到吗
$hash = bcrypt(hmac($userpassphrase,$pepper),$salt)
有意义地优于
$hash = bcrypt($userpassphrase,$salt)
考虑到管理/存储 $pepper 和 $salt 的额外负担？
我的假设是 hmac 并没有显着地增强产生的 $hash，并且存储 $pepper 的负担超过了任何假定的好处……但我很想听听有见地的意见。
密钥哈希或 HMac 用于验证数据来源，而不是用于密码保护。例如，如果你和我有一个共享密钥，我可以将一些数据与计算出的 hmac 一起发送给你，你可以使用相同的密钥来检查 hmac 哈希是否匹配，如果匹配，你就知道数据来自我，并没有被改变。
您无法在机器上有效地隐藏攻击者无法访问的秘密密码，您所要做的就是增加一层隐秘性。在没有共享密钥的情况下使用 HMac 与使用 SHA($userpassphrase, $salt) 基本相同，这很容易计算，因此一旦“秘密”不会为您的密码哈希方案添加任何有意义的安全性" 密码是已知的。
bcrypt 的全部目的只是为了减慢哈希过程，因此攻击者需要很长时间才能为你的 salt 生成彩虹表。如果您想让您的密码哈希方案更安全，只需增加原始哈希函数的成本即可。在 bcrypt 中，您可以指定“logRounds”的数量（我认为这就是他们所说的），即执行散列的次数。如果将 logRounds 指定为 15（默认值为 10），则哈希将执行 2^15 = 32768 次，这会显着减慢速度。执行散列所需的时间越长，攻击者破解它所需的时间就越长。
我不确定你想如何使用它。假设您存储 $hash 稍后进行质询响应身份验证，那么您需要将 $pepper 发送给客户端，它只是另一种盐。简单地添加一个 HMAC 不会有太大用处。
在 bcrypt 之类的密码扩展函数上添加额外的哈希是没有意义的。再重复几次会更容易更好。
“胡椒”是一种常用但有问题的做法；我个人认为，攻击者获取您的数据库但无法访问您的密钥的攻击模型是人为设计的，因此对它们进行保护不值得导致实现的复杂性。