最佳实践：Salting & Peppering 密码？

好的。鉴于我需要写这个 over 和 over，我将仅针对胡椒做最后一个规范答案。

辣椒的明显优势

辣椒应该使哈希函数更安全似乎很明显。我的意思是，如果攻击者只获取您的数据库，那么您的用户密码应该是安全的，对吧？看起来合乎逻辑，对吧？

这就是为什么这么多人认为辣椒是个好主意的原因。这说得通”。

辣椒的现实

在安全和密码学领域，“有意义”是不够的。某些东西必须是可证明且有意义的，才能被认为是安全的。此外，它必须以可维护的方式实现。无法维护的最安全的系统被认为是不安全的（因为如果该安全性的任何部分发生故障，整个系统就会崩溃）。

辣椒既不适合可证明的模型，也不适合可维护的模型……

辣椒的理论问题

现在我们已经做好了准备，让我们看看辣椒有什么问题。

将一个哈希输入另一个哈希可能很危险。在您的示例中，您执行 hash_function($salt . hash_function($pepper . $password))。从过去的经验中我们知道，将一个哈希结果“输入”到另一个哈希函数会降低整体安全性。原因是这两个哈希函数都可能成为攻击的目标。这就是为什么像 PBKDF2 这样的算法使用特殊操作来组合它们（在这种情况下是 hmac）。关键是，虽然这没什么大不了的，但随便乱扔也不是一件小事。加密系统旨在避免“应该工作”的情况，而是专注于“设计为工作”的情况。虽然这看起来纯粹是理论上的，但实际上并非如此。例如，Bcrypt 不能接受任意密码。因此，如果 hash() 返回二进制字符串，则传递 bcrypt(hash(pw), salt) 确实会导致比 bcrypt(pw, salt) 弱得多的哈希。

针对设计工作 bcrypt（和其他密码散列算法）的设计方式是使用盐。辣椒的概念从未被引入。这似乎是一件小事，但事实并非如此。原因是盐不是秘密。它只是一个攻击者可以知道的值。另一方面，根据定义，辣椒是密码学的秘密。当前的密码散列算法（bcrypt、pbkdf2 等）都被设计为只接受一个秘密值（密码）。根本没有研究在算法中添加另一个秘密。这并不意味着它不安全。这意味着我们不知道它是否安全。安全和密码学的一般建议是，如果我们不知道，那就不知道。因此，在密码学家设计和审查算法以用于秘密值（辣椒）之前，当前的算法不应与它们一起使用。

复杂性是安全的敌人 信不信由你，复杂性是安全的敌人。制作一个看起来很复杂的算法可能是安全的，也可能不是。但是它不安全的可能性非常大。

辣椒的重大问题

它是不可维护的 您对辣椒的实现排除了旋转辣椒键的能力。由于胡椒用于单向函数的输入，因此您永远不能在值的生命周期内更改胡椒。这意味着你需要想出一些奇怪的技巧来让它支持密钥轮换。这是非常重要的，因为每当您存储加密机密时都需要它。没有一种机制来轮换密钥（定期轮换，以及在违规之后）是一个巨大的安全漏洞。而您当前的辣椒方法将要求每个用户要么通过轮换使他们的密码完全失效，要么等到他们的下一次登录轮换（可能永远不会）......这基本上使您的方法立即不可行。

它需要你推出自己的加密货币 由于当前没有算法支持辣椒的概念，因此它需要你编写算法或发明新的算法来支持辣椒。如果你不能立即明白为什么这是一件非常糟糕的事情：任何人，从最无知的业余爱好者到最好的密码学家，都可以创建一个他自己无法破解的算法。 Bruce Schneier 永远不要推出自己的加密货币......

布鲁斯·施奈尔

更好的方式

因此，在上面详述的所有问题中，有两种处理这种情况的方法。

只使用现有的算法如果您正确使用 bcrypt 或 scrypt（成本很高），那么除了最弱的字典密码之外，所有密码都应该在统计上是安全的。以成本 5 散列 bcrypt 的当前记录是每秒 71k 散列。以这种速度，即使是 6 个字符的随机密码也需要数年时间才能破解。考虑到我的最低推荐成本是 10，这将每秒哈希值减少了 32 倍。所以我们只会谈论每秒 2200 个哈希值。以这种速度，即使是某些字典短语或修饰语也可能是安全的。此外，我们应该在门口检查那些弱密码类别，不允许他们进入。随着密码破解越来越先进，密码质量要求也应该如此。它仍然是一个统计游戏，但有了适当的存储技术和强大的密码，每个人都应该非常安全......

在存储之前加密输出哈希 在安全领域中存在一种算法，旨在处理我们上面所说的一切。这是一个分组密码。这很好，因为它是可逆的，所以我们可以旋转密钥（耶！可维护性！）。这很好，因为它按设计使用。这很好，因为它没有给用户任何信息。让我们再看看那条线。假设攻击者知道您的算法（这是安全所必需的，否则它是通过晦涩难懂的安全性）。使用传统的辣椒方法，攻击者可以创建一个哨兵密码，并且由于他知道盐和输出，他可以暴力破解辣椒。好吧，这是一个很长的镜头，但它是可能的。使用密码，攻击者一无所获。而且由于盐是随机的，因此哨兵密码甚至对他/她没有帮助。所以他们剩下的最好的就是攻击加密的形式。这意味着他们首先必须攻击您的加密哈希以恢复加密密钥，然后再攻击哈希。但是有很多关于密码攻击的研究，所以我们希望依靠它。

TL/DR

不要用辣椒。它们存在许多问题，有两种更好的方法：不使用任何服务器端机密（是的，没关系）和在存储之前使用块密码加密输出哈希。

---

拳头我们应该谈谈辣椒的确切优势：

Pepper 可以保护弱密码免受字典攻击，在特殊情况下，攻击者可以读取数据库（包含哈希）但无权访问 Pepper 的源代码。

一个典型的场景是 SQL 注入、丢弃的备份、丢弃的服务器……这些情况并不像听起来那么罕见，而且通常不受您的控制（服务器托管）。如果你使用...

每个密码唯一的盐

像 BCrypt 这样的慢速哈希算法

...强密码得到很好的保护。在这些条件下，几乎不可能暴力破解强密码，即使知道盐。问题是弱密码，它们是暴力字典的一部分，或者是它们的派生词。字典攻击会很快发现这些，因为您只测试最常见的密码。

第二个问题是辣椒怎么涂？

一种经常推荐的应用辣椒的方法是在将密码和辣椒传递给散列函数之前将其组合起来：

$pepperedPassword = hash_hmac('sha512', $password, $pepper);
$passwordHash = bcrypt($pepperedPassword);

还有另一种更好的方法：

$passwordHash = bcrypt($password);
$encryptedHash = encrypt($passwordHash, $serverSideKey);

这不仅允许添加服务器端机密，还允许在必要时交换 $serverSideKey。此方法涉及更多工作，但如果代码曾经存在（库），则没有理由不使用它。

---

盐和胡椒的目的是增加预先计算的密码查找的成本，称为彩虹表。

一般来说，试图找到单个哈希的冲突是很困难的（假设哈希是安全的）。但是，使用短散列，可以使用计算机生成所有可能的散列到硬盘上的查找中。这被称为彩虹表。如果您创建一个彩虹表，您就可以进入世界并快速找到任何（未加盐未加胡椒的）哈希的合理密码。

胡椒的目的是使破解密码列表所需的彩虹表独一无二。从而浪费了攻击者更多的时间来构建彩虹表。

然而，盐的重点是让每个用户的彩虹表对用户来说是唯一的，从而进一步增加了攻击的复杂性。

实际上，计算机安全的重点几乎从不使其（数学上）不可能，只是在数学上和物理上不切实际（例如，在安全系统中，它需要宇宙中的所有熵（以及更多）来计算单个用户的密码）。

---

我希望这是关于盐和胡椒的讨论，而不是特定的算法，但我使用的是安全算法

我知道的每个安全密码散列函数都将密码和盐（以及秘密/胡椒，如果支持）作为单独的参数，并自行完成所有工作。

仅仅因为您连接字符串并且您的 hash_function 只接受一个参数这一事实，我知道您没有使用那些经过充分测试、充分分析的标准算法之一，而是试图推出自己的算法。不要那样做。

Argon2 在 2015 年赢得了密码哈希竞赛，据我所知，它仍然是新设计的最佳选择。它通过 K 参数（称为“秘密值”或“密钥”）支持胡椒。我知道没有理由不使用胡椒粉。在最坏的情况下，辣椒将与数据库一起受到损害，并且您的情况并不比您没有使用它更糟。

如果您不能使用内置的胡椒支持，您可以使用来自 this discussion 的两个建议公式之一：

Argon2(salt, HMAC(pepper, password))   or   HMAC(pepper, Argon2(salt, password))

重要提示：如果您将 HMAC（或任何其他散列函数）的输出传递给 Argon2（或任何其他密码散列函数），请确保密码散列函数支持嵌入的零字节或对散列值进行编码（例如在 base64 ) 以确保没有零字节。如果您使用的语言的字符串支持嵌入的零字节，那么您可能是安全的，unless that language is PHP，但我还是会检查一下。

---

看不到在源代码中存储硬编码值具有任何安全相关性。这是通过默默无闻的安全。

如果黑客获取了您的数据库，他将能够开始暴力破解您的用户密码。如果那个黑客设法破解了几个密码，他很快就会识别出你的辣椒。

---