php - 了解 PHP password_hash 使用的 bcrypt salt

Question

我在理解 bcrypt 如何使用盐时遇到了一些麻烦。我知道盐有什么用，但我不明白盐值是如何使用的。

问题 1: 正确的盐长度是多少？

我发现的所有来源都说，盐的长度为 22，并且它与算法、成本和结果字符串中的实际哈希值一起存储。



但是，我发现的所有实现都使用长度为 32 的盐。例如 FOSUserBundle 使用的 Symfony 使用以下代码来创建盐:

$this->salt = base_convert(sha1(uniqid(mt_rand(), true)), 16, 36)

由于 sha1 哈希长度为 32 个字符，因此生成的 salt 的长度也为 32。 这只是一个懒惰的实现，跳过将字符串修剪为 22 长度的代码，因为这是由 bcrypt 自己完成的吗？还是出于某种原因需要 32 个字符？

问题2: 22 的salt 长度真的正确吗？

在以下示例中，似乎只有盐的前 21 个字符保存在结果字符串中。将这 21 个字符作为 salt 传递给 password_hash 将导致错误，但填充 0 将起作用:

$s = 'password';
$salt        = 'salt5678901234567890123456789012';
$salt_prefix = 'salt567890123456789010'; // first 21 chars of salt + 0

$h1 = password_hash($s, PASSWORD_BCRYPT, array('salt' => $salt));
$h2 = password_hash($s, PASSWORD_BCRYPT, array('salt' => $salt_prefix));

echo $h1 . PHP_EOL;
echo $h2 . PHP_EOL;

//Result
$2y$10$salt56789012345678901uTWNlUnhu5K/xBrtKYTo7oDy8zMr/csu
$2y$10$salt56789012345678901uTWNlUnhu5K/xBrtKYTo7oDy8zMr/csu

因此，需要将至少包含 22 个字符的盐传递给算法，但第 22 个字符似乎没用。那是对的吗？如果根本不使用第 22 个字符，它的意义是什么？

问题三: 为什么不手动指定盐？

在 PHP 函数 password_hash 中，不推荐使用手动散列。相反，鼓励自动让 password_hash ，因为这样会更安全。

我知道对所有密码使用“弱”盐或相同的盐会导致彩虹表带来的风险。但为什么一般使用自动生成的盐更安全？

为什么使用自动生成的盐而不是手动生成的盐更安全，生成如下:

$this->salt = base_convert(sha1(uniqid(mt_rand(), true)), 16, 36)

问题 4: password_hash 是否有任何替代品仍然允许使用自定义盐？

由于我正在执行的项目的实现，我需要控制用于生成密码哈希的盐。这可以在 future 改变，但正确知道有必要手动设置盐。由于此功能在 password_hash 中已弃用，因此我需要一些替代方法来生成哈希。这该怎么做？

编辑:

简单解释一下为什么我需要控制盐:密码不仅用于直接登录 Web 应用程序，还用于通过 REST API 连接到应用程序。客户端从服务器请求盐并使用它(算法和成本已知)来散列密码，用户在客户端输入。

然后将散列密码发送回服务器进行身份验证。目的是不以纯文本形式发送密码。为了能够在客户端和服务器上生成相同的哈希值，客户端需要知道服务器使用的是哪种盐。

我知道散列密码不会增加任何真正的安全性，因为通信已经只使用 HTTPS。然而，这是客户端当前操作的方式:如果客户端发回正确的密码哈希，则授予身份验证。

我无法在不破坏数千个现有客户端的情况下更改服务器端。客户端可以在 future 某个时候更新，但这将是一个漫长的过程。

既然这样做了，我需要遵循旧的流程，这意味着我需要能够告诉客户盐。

但是我做 而不是 需要自己生成盐。如果 PHP 知道如何执行此操作的最安全方法，我完全没问题。但是我确实需要以某种方式获取/提取盐，然后将其发送给客户。

如果我理解正确，我可以让 password_hash 完成工作，然后从结果字符串中提取字符 7-29。这样对吗？

Answer 1

Problem 1: What is the correct salt length?

All sources I found say, that the salt has a length of 22 and that it is stored together with the algorithm, the costs and the actual hash value in the result string.

如果所有消息来源都这么说，那么您就没有理由质疑...
没有通用的盐大小，它取决于算法，对于 bcrypt，它是 22 ......尽管有一个问题。所需的大小实际上是 16 字节，但这实际上是 Base64 编码的 (*)。
当您对 16 个字节的数据进行 Base64 编码时，将产生一个 24 个字符长度的 ASCII 字符串，最后 2 个字符是不相关的 - 当您修剪这 2 个不相关的字符时，该字符串变为 22。
为什么它们无关紧要？你的问题已经足够广泛了......阅读 Wikipedia page for Base64 。
* 实际上有一些 Base64“方言”，bcrypt 使用的与 PHP 的 base64_encode() 不太一样。

However, all implementations I found, use a salt with length 32. For example the FOSUserBundle used by Symfony used the following code to creat the salt:

$this->salt = base_convert(sha1(uniqid(mt_rand(), true)), 16, 36)

Since a sha1 hash is 32 chars long, the generated salt also has a length of 32. Is this just a lazy implementation, skipping the code to trim the string to a length of 22 because this is done by bcrypt it self? Or are 32 chars necessary for some reason?

该行将产生一个 31 个字符的字符串，而不是 32 个，但这实际上并不相关。如果您提供更长的字符串，则只会使用其中必要的部分——最后那些字符将被忽略。
你可以自己测试一下:

php > var_dump(password_hash('foo', PASSWORD_DEFAULT, ['salt' => str_repeat('a', 22).'b']));
string(60) "$2y$10$aaaaaaaaaaaaaaaaaaaaaO8Q0BjhyjLkn5wwHyGGWhEnrex6ji3Qm"
php > var_dump(password_hash('foo', PASSWORD_DEFAULT, ['salt' => str_repeat('a', 22).'c']));
string(60) "$2y$10$aaaaaaaaaaaaaaaaaaaaaO8Q0BjhyjLkn5wwHyGGWhEnrex6ji3Qm"
php > var_dump(password_hash('foo', PASSWORD_DEFAULT, ['salt' => str_repeat('a', 22).'d']));
string(60) "$2y$10$aaaaaaaaaaaaaaaaaaaaaO8Q0BjhyjLkn5wwHyGGWhEnrex6ji3Qm"

(如果使用了额外的字符，则生成的哈希值会有所不同)
我不熟悉那个 FOSUserBundle，但是是的 - 它看起来只是在做一些懒惰且不正确的事情。

Problem 2: Is a salt length of 22 really correct?

In the following example it seems, that only the first 21 chars of the salt are saved in the result string. Passing these 21 chars as salt to password_hash will result in an error, but padding a 0 will work:

$s = 'password';
$salt        = 'salt5678901234567890123456789012';
$salt_prefix = 'salt567890123456789010'; // first 21 chars of salt + 0

$h1 = password_hash($s, PASSWORD_BCRYPT, array('salt' => $salt));
$h2 = password_hash($s, PASSWORD_BCRYPT, array('salt' => $salt_prefix));

echo $h1 . PHP_EOL;
echo $h2 . PHP_EOL;

//Result
$2y$10$salt56789012345678901uTWNlUnhu5K/xBrtKYTo7oDy8zMr/csu
$2y$10$salt56789012345678901uTWNlUnhu5K/xBrtKYTo7oDy8zMr/csu

So, one needs to pass a salt with at least 22 chars to the algorithm but the 22nd chars seems to be useless. Is that correct? What is the sense of the 22nd char if it is not used at all?

这并不是无关紧要的......用例如填充它'A'，你会看到不同的结果。
老实说，我无法正确解释这一点，但这又是由 Base64 的工作方式 和 引起的，因为在生成的哈希中，您实际上看到了与此类似的内容(伪代码):

base64_encode(  base64_decode($salt) . $actualHashInBinary  )

也就是说，(据说)Base64 编码的盐首先被解码为原始二进制，用于创建实际的散列(再次以原始二进制)，将两者连接起来，然后整个事情是 Base64 编码的。
由于输入盐实际上是 24 大小全长中的 22 相关，我们实际上在末尾有一个不完整的块，它在原始散列的开头完成(填充？)...
连接 2 个单独的 Base64 编码值和在 Base64 编码之前连接原始值是另一回事。

Problem 3: Why not specify the salt manually?

In the PHP function password_hash using a manual hash is deprecated. Instead one is encouraged to let password_hash automatically, since would be saver.

I understand that using a "weak" salt or the same salt for all passwords can lead to risks due to rainbow tables. But why is it saver to use the auto-generated salt in general?

简而言之 - 盐需要加密安全(即不可预测)，而 PHP 已经知道如何做到这一点，而您很可能(绝大多数情况下)不知道如何做到这一点。
除非您有实际的硬件 CSPRNG(PHP 尚未配置为使用)，否则您能做的最好的事情就是让 PHP 自动生成盐。
然而，我们在这里，您显然想要做相反的事情(无论出于何种原因)并在此过程中降低安全性 - 很多人都这样做。
这就是盐选项被弃用的原因 - 以保护您免受自己的伤害。 :)

Why is it saver to use the auto-generated salt instead of manual salt, that is generated like this:

$this->salt = base_convert(sha1(uniqid(mt_rand(), true)), 16, 36)

正如我所说，盐需要是不可预测的。在这个特定的例子中 - 使用的函数都不是不可预测的，甚至 mt_rand() 。
是的，mt_rand() 实际上并不是随机的，尽管它的名字暗示了它。

Problem 4: Is there any replacement for password_hash that still allows the usage of a custom salt?

Due to the implementation of project I am working on, I need to control the salt, that is used to generate a password hash. This can be changed in the future, but right know it is necessary to set the salt manually. Since this feature is deprecated in password_hash, I need some alternative to generate the hash. How to do this?

你没有。
您的项目绝对没有理由决定如何生成 password_hash() salt。我不知道你为什么认为这是必要的，但 100% 不是 - 这毫无意义。
尽管如此，最终 - 这就是为什么在删除某些内容之前会进行弃用。现在您知道盐选项将在 future 被移除，并且您有足够的时间来重构您的应用程序。
明智地使用它，不要试图复制已弃用的功能。您应该朝着相反的方向工作 - 询问如何在不破坏您的应用程序的情况下将两者分开。