密码哈希：加盐+胡椒粉还是盐足够？

$verifier = $salt + hash( $salt + $password )

#1 楼

在某些情况下，花椒会有所帮助。
作为一个典型的例子，假设您正在构建一个Web应用程序。它由webapp代码（在某些webapp框架中运行，ASP.NET MVC，在Python上的金字塔无关紧要）和用于存储的SQL数据库组成。 Webapp和SQL DB在不同的物理服务器上运行。
对数据库的最常见攻击是成功的SQL Injection Attack。这种攻击不一定能访问您的Web应用程序代码，因为Web应用程序在不同的服务器和用户ID上运行。
您需要将密码安全地存储在数据库中，并以：

$hashed_password = hash( $salt . $password )

其中$salt与$hashed_password表示形式一起以明文形式存储在数据库中，并为每个新的或更改的密码随机选择。 hash是一种缓慢的加密安全哈希函数，请参阅https://security.stackexchange.com/a/31846/10727了解更多背景知识。
问题是，添加常数几乎为零。值，并且在SQL注入攻击期间通常不会破坏应用程序代码，那么下面的代码是否比上面的代码好得多？

$hashed_password = hash( $pepper . $salt . $password )

其中$salt以明文形式存储在数据库中，而$pepper是一个co nstant以明文形式存储在应用程序代码中（如果在多个服务器上使用该代码或源是公共的，则进行配置）。
添加此$pepper很容易-您只需在代码中创建一个常量，然后在其中输入一个较大的加密安全随机值（例如来自/ dev / urandom hex或base64编码的32byte），然后在密码哈希中使用该常量功能。如果您已有用户，则需要迁移策略，例如，在下次登录时重新哈希密码，并在哈希旁边存储密码哈希策略的版本号。
答案：
使用$pepper确实会增加如果数据库受到破坏并不意味着应用程序受到破坏，则密码散列的强度。在不了解Pepper的情况下，密码仍然完全安全。由于存在特定于密码的盐，您甚至无法找出数据库中的两个密码是否相同。
原因是hash($pepper . $salt . $password)有效地构建了以$pepper作为键，$salt.$password作为输入的伪随机函数（对于健全的hash候选对象，例如具有SHA *，bcrypt或scrypt的PBKDF2）。伪随机函数的两个保证是，您不能从秘密密钥下的输出推论输入，也不能在不知道密钥的情况下从输入推论输出。这听起来很像哈希函数的单向属性，但是不同之处在于，使用像密码这样的低熵值，您可以有效地枚举所有可能的值，并在公共哈希函数下计算图像，从而找到其值图像与原图像匹配。使用伪随机函数，没有键就无法做到这一点（即没有辣椒），因为没有键就无法计算单个值的图像。
如果您可以长时间访问数据库并且仍然可以从外部正常使用该应用程序，则$salt在此设置中的重要作用将发挥作用。如果没有$salt，则可以将您控制的帐户的密码设置为已知值$passwordKnown，然后将哈希值与未知密码$passwordSecret的密码进行比较。与hash($pepper . $passwordKnown)==hash($pepper . $passwordSecret)一样，当且仅当$passwordKnown==$passwordSecret可以将未知密码与任何选定值进行比较（出于技术上的考虑，我假设哈希函数具有抗冲突性）。但是，只有当分别为hash($pepper . $salt1 . $passwordKnown)==hash($pepper . $salt2 . $passwordSecret)和$salt1 . $passwordKnown == $salt2 . $passwordSecret随机选择$salt1和$salt2和$passwordKnown时，使用盐才能得到$passwordSecret，盐将永远不会相同（假设随机数足够大，例如256bit），因此您将无法再将密码与彼此。

#2 楼

（注意：使用盐仅是工作的一半；您还需要使散列函数变慢-因此攻击单个低熵密码仍然很困难。缓慢性通常是通过多次迭代或对盐和密码的10000个副本。）

您的“胡椒粉”所做的是将哈希转换为MAC。用散列函数创建一个好的，安全的MAC并不容易，因此，您最好使用HMAC而不是自制的构造（理论上的说法是，抗冲突的散列函数不一定与随机预言是无法区分的）。

使用MAC，您可以从以下角度获得一些安全性：攻击者对数据库的读取访问可能不再是一个真正的问题。 MAC密钥（“ pepper”）可以集中保密性需求。但是，这依赖于MAC也是一种单向函数，这是您可以从许多MAC构造（包括HMAC）中获得的属性，但是从密码上来说，并不能真正保证它的存在（有些微妙之处）。 br />“胡椒粉”意味着您需要管理一个密钥，包括以一种不会重启的方式进行的安全存储。密钥很小并且适合RAM，但是由于存储要求，还不清楚它是否真正提高了安全性。可以读取整个数据库的攻击者通常还可以读取整个硬盘，包括任何“受保护的”文件。较小的按键可能允许某些高级设置，例如密钥存储在智能卡上，该智能卡在引导时使用，但之后未保持连接状态。综上所述，加薪是否值得付出的努力完全取决于具体情况，总的来说，为了避免增加复杂性，我建议不要这样做。

#3 楼

我想指出一下胡椒真正可以做什么。

什么时候胡椒有帮助？只要攻击者可以访问数据库中的哈希值，但无法控制服务器，因此就不知道这个问题。这对于SQL注入来说是典型的，因为它很容易做到，可能是更常用的攻击之一。

Pepper有什么改进？

/>
即使正确使用了慢速键派生功能，也可以通过字典攻击轻松获得此密码。将最常用的密码放入字典中，并使用此弱密码进行暴力破解。

$hashValue = bcrypt('12345', $cost, $salt);

在胡椒中，弱密码的长度增加，现在包含特殊字符，并且更重要的是，您不会在字典中找到它。因此，只要Pepper保持秘密，它就可以防止字典攻击，在这种情况下，它可以保护弱密码。

编辑：

有一种更好的添加方法服务器端密钥，而不是用作胡椒粉。使用胡椒，攻击者必须在服务器上获得其他特权才能获取密钥。通过首先计算哈希，然后使用服务器端密钥对哈希进行加密（双向加密），我们可以获得相同的优势。这使我们可以选择在必要时交换密钥。

$hashValue = bcrypt('12345anm8e3M-83*2cQ1mlZaU', $cost, $salt);

#4 楼

关于Unix密码的盐化和迭代发明的论文（Password Security：A Case History，Morris＆Thompson，1978年）也描述了胡椒的等效性：


用户密码的八个字符用作DES的密钥。然后使用该算法对常量进行加密。尽管此常量在
时刻为零，但它易于访问并且可以依赖于安装。


我还没有听说过使用它。还有其他人吗？

#5 楼

只是一个顺便说一句，新的NIST数字身份准则（草案）强烈建议也使用Pepper：

https://pages.nist.gov/800-63-3/sp800-63b.html ＃sec5

5.1.1.2记忆的秘密验证程序：


...一个带键的哈希函数（例如HMAC [FIPS198-1]）与散列的身份验证器分开存储（例如，在硬件安全模块中）的存储应该用于进一步抵抗针对存储的散列的身份验证器的字典攻击。

#6 楼

请考虑以下情形：

我将使用SQL注入闯入网站X，以检索用户列表以及其密码哈希和盐。假设网站X也在使用全局Pepper。

我要做的就是在SQL注入之前使用我知道的用户名和密码在网站X上注册一个用户。然后，对于数据库中的特定记录，我会知道密码哈希，纯文本密码，salt（以纯文本存储），而根据这一记录，对我来说，破解全局胡椒将在计算上变得微不足道。

所以，实际上，胡椒粉可以使攻击者在微不足道的开销时间内减速。他们不必像预期那样强行使用密码+盐+胡椒粉。

以上是选择的明文攻击形式。只要攻击者知道算法（hash（）），输出（$ hashed_pa​​ssword）以及除输入之外的所有输入（“ constants” $ salt＆$ password和“ variable” $ pepper），他们就可以“求解x就像线性代数方程式（h = s + p + x == hsp = x），但当然是蛮力。使Pepper的长度超过bcrypt的限制56字节（448位），增加了时间成本，与bcrypt一样好，但仍不如scrypt好。因此，只要胡椒足够长，它就是一种进步。

#7 楼

对服务器如何隐藏全局Pepper常量不是很熟悉，但我的看法是，渗透到服务器中的黑客迟早会弄清楚如何获取Pepper的价值。
要获得Pepper的价值完全安全将需要特殊的硬件。一种方法是使用服务器中安装的FPGA板。 FPGA将包含用于执行哈希的代码，包括Pepper值，并且所有哈希计算都在FPGA内部进行。使用FPGA，编程可以是一种单向功能。可以对胡椒进行编程，但没有指令可以发送以将其读出。胡椒粉将存储在锁在保险箱中的纸上。
如果Pepper是随机生成的128个以上的位，则没有确定它的实用方法。