我遇到了一个讨论，在该讨论中，我了解到我实际上在做的并不是给密码加盐，而是给它们添加了胡椒粉，从那时起，我就开始使用以下功能：

hash_function($salt.hash_function($pepper.$password)) [multiple iterations]

忽略选择的哈希算法（我希望这是关于盐和胡椒的讨论，而不是特定算法的讨论，但我使用的是安全算法），这是安全的选择还是我应该做一些不同的事情？对于那些不熟悉这些术语的人：

• 甲盐是通常存储与设计，使其不可能使用哈希表来破解密码的数据库中的字符串中的随机生成值。由于每个密码都有自己的特色，因此必须将所有密码单独强行破解。但是，由于盐与密码哈希一起存储在数据库中，因此数据库泄密意味着同时丢失两者。

• 甲胡椒是从中旨在是秘密的数据库（在应用程序的源代码通常硬编码）分开存储站点范围静态值。使用它是为了避免对数据库造成危害，不会导致整个应用程序的密码表都是蛮力的。

我有什么遗漏的东西吗？保护密码安全的最佳选择是保护我的用户的安全吗？这样做是否有潜在的安全缺陷？

注意：出于讨论目的，假设应用程序和数据库存储在单独的计算机上，不共享密码等，因此违反数据库服务器并不自动意味着违反了应用程序服务器。

好。眼看着，因为我需要写这个了，并过，我会独自做最后一次典型的答案对辣椒。

辣椒的明显上升

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

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

辣椒的现实

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

辣椒既不适合可验证的模型，也不适合可维护的模型。

辣椒的理论问题

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

• 将一个哈希值馈入另一个哈希值可能很危险。

  在您的示例中，您这样做hash_function($salt . hash_function($pepper . $password))。

  从过去的经验中我们知道，仅将一个哈希结果“馈入”另一个哈希函数会降低整体安全性。原因是两个哈希函数都可能成为攻击的目标。

  这就是为什么像PBKDF2这样的算法使用特殊的运算来组合它们（在这种情况下为hmac）的原因。

  关键是，尽管这没什么大不了的，但扔掉它也不是一件小事。加密系统旨在避免出现“应该工作”的情况，而是集中于“旨在工作”的情况。

  尽管这似乎纯粹是理论上的，但实际上并非如此。例如，Bcrypt不能接受任意密码。所以路过bcrypt(hash(pw), salt)的确可以导致远弱哈希比bcrypt(pw, salt)如果hash()返回的二进制字符串。

• 反对设计

  bcrypt（和其他密码哈希算法）的设计方法是使用盐。从未引入胡椒的概念。这看似微不足道，但事实并非如此。原因是盐不是秘密。这只是攻击者可以知道的值。另一方面，从定义上讲，胡椒粉是加密的秘密。

  当前的密码哈希算法（bcrypt，pbkdf2等）均设计为仅采用一个秘密值（密码）。完全没有研究过向该算法添加其他秘密。

  这并不意味着它不安全。这意味着我们不知道它是否安全。安全性和加密技术的一般建议是，如果我们不知道，那就不是。

  因此，在密码学家设计和审查用于秘密值（辣椒）的算法之前，不应将当前算法与它们一起使用。

• 复杂性是安全的敌人

  信不信由你，复杂性就是安全的敌人。使算法看起来很复杂可能是安全的，也可能不是。但是，这种方法并不安全的可能性很大。

辣椒的重大问题

• 这是无法维护的

  您对胡椒的实现无法旋转胡椒键。由于在单向功能的输入处使用了花椒，因此在该值的整个生命周期内都无法更改花椒。这意味着您需要提出一些怪异的技巧来使其支持密钥旋转。

  这是非常重要的，因为每当您存储加密机密时都需要它。没有机制（周期性地和在破坏之后）旋转密钥是一个巨大的安全漏洞。

  您当前的Pepper方法将要求每个用户轮换让其密码完全无效，或者等到他们的下一次登录轮换使用（这可能永远不会）...

  基本上，这使您的方法立竿见影。

• 它要求您滚动自己的加密货币

  由于当前没有算法支持胡椒的概念，因此您需要编写算法或发明新的算法来支持胡椒。而且，如果您无法立即看到为什么这是一件非常糟糕的事情：

  从最笨拙的业余爱好者到最好的密码学家，任何人都可以创建自己无法破解的算法。

  • 布鲁斯·施耐尔

  永远不要投出自己的加密货币...

更好的方法

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

• 只需使用现有的算法

  如果您正确地使用bcrypt或scrypt（代价高昂），则除最弱的字典密码以外的所有密码都应在统计上安全。以成本5哈希bcrypt的当前记录是每秒71,000个哈希。以这种速度，即使是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（如果需要）。该方法需要更多的工作，但是如果代码一旦存在（库），则没有理由不使用它。

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

通常，很难为单个哈希找到冲突（假设哈希是安全的）。但是，如果哈希值很短，则可以使用计算机将所有可能的哈希值生成到硬盘上的查找中。这称为彩虹表。如果创建彩虹表，则可以进入世界，并快速找到任何（未加盐且未加盐的）哈希的合理密码。

胡椒的重点是使破解您的密码列表所需的彩虹表独特。因此，浪费了更多的时间在攻击者身上以构建彩虹表。

然而，重点在于使每个用户的彩虹表对于用户而言是唯一的，从而进一步增加了攻击的复杂性。

实际上，计算机安全的要点几乎是从来没有（在数学上）使其不可能，而在数学上和物理上都不可行（例如，在安全系统中，它将利用Universe中的所有熵（甚至更多）来计算单个用户的密码）。

无法看到在源代码中存储硬编码值具有任何安全性。默默无闻是安全性。

如果黑客获取了您的数据库，他将能够开始强行强制使用您的用户密码。如果该黑客设法破解了一些密码，那么很快就可以识别您的胡椒。