“胡椒”是在散列之前附加到密码的秘密应用程序范围的随机值。这确保了攻击者无法在不以某种方式损害辣椒值的情况下实际破解密码哈希。这与通常不是秘密并与密码哈希一起附加的盐不同。

如果操作正确，这将有助于确保对您的系统具有有限访问权限的攻击者将无法破解您存储的密码。这是一个很常见的场景。想象一下，一个攻击者发现了允许他转储您的密码数据库的 SQL 注入攻击。如果没有存储在他无法获取的配置文件中的胡椒，他将无法破解这些密码。

话虽如此，我认为辣椒并不普遍。我不知道有任何开箱即用的密码哈希库，而且我从未在自己的应用程序中使用过它。

“胡椒”是一个秘密值，您认为它是攻击者无法触及的。您对密码进行哈希处理是因为您认为攻击者可以瞥见您的服务器内脏（参见此处进行讨论）。如果您认为瞥见是部分的，“胡椒”会增加额外的安全性：例如，攻击者可以读取数据库的内容（SQL 注入攻击的常见结果），但不能读取Web 服务器本身的配置文件。

没有胡椒，获得散列密码的攻击者可以“在家尝试密码”，因为他可以对任何潜在密码重新计算相同的散列，并查看结果是否与他从您的服务器窃取的内容相匹配。但是如果哈希计算是“peppered”，那么攻击者就无法在家计算哈希，除非他也知道胡椒值。从密码学上讲，“pepper”是一个密钥，将其插入散列过程会将散列函数转换为MAC。辣椒与秘密一样有价值，即攻击者无法猜到。

有关密码散列的入门知识，请参阅此答案。有一节关于胡椒粉（接近尾声）。请记住，密码散列只有在攻击者的违规行为是部分的（他只有只读的偷看）时才有意义，并且只有当违规行为是双重部分时才有意义：攻击者不仅获得了只读的偷看，而且该偷窥不适用于完整的服务器内容。当将假设叠加在其他假设之上时，在某些时候它不再是现实的，值得付出努力；这就是为什么在实践中胡椒粉往往很少见的原因。

“Peppering”进入了廉价的类似 HSM 的设备可行的领域，这很有意义。如果您的目标是纯软件解决方案，那么辣椒的用处充其量是值得商榷的。如果你确实使用了胡椒粉，至少要做到这一点。

即，对于用户密码p和辣椒k，计算 HMAC( p , k )（以辣椒k作为HMAC的密钥计算p的HMAC；如果可能，请使用 HMAC/SHA-256，尽管 HMAC/SHA-1 会在实践中没问题）。然后，在“普通”密码散列函数中使用 HMAC 输出，完成唯一/随机盐和许多迭代，如bcrypt或PBKDF2（不，胡椒粉不会消除对良好盐的需要）。HMAC/SHA-256 生成 32 字节的二进制输出，您可能需要将其转换为字符如果您的 bcrypt 或 PBKDF2 库需要字符；Base64会将 32 个字节转换为 44 个字符。如果攻击者成功获得散列密码和胡椒值，“正常散列”旨在确保一定程度的稳健性。如果按照我上面解释的方式将 HMAC 和 bcrypt/PBKDF2 结合起来，那么至少，“胡椒”不会使您的服务器变弱，这在进行自制密码学时总是存在风险。