使用 bcrypt 时应该在表中存储什么

Question

我正在查看this article 并找到了以下格式的哈希，这是我们使用 bcrypt 时返回的。我发现这个哈希应该存储在数据库中（以 varchar(60) 格式左右），并在需要任何用户身份验证时使用。

我的疑问是，如果我的数据库遭到入侵，攻击者将已经知道我使用的算法、成本和盐，这将使他的工作变得非常容易。我是这么认为的，因为现在他甚至不需要猜测他必须使用的算法（bcrypt、SHA、MD5 等）来通过暴力破解获取用户的密码。

相反，我觉得我应该只使用最后一部分（最后一个 $ 之后的部分）并在我的脚本中添加另一部分，然后像这样匹配

<?php

$options = array('cost' => 11);
echo password_hash("akki", PASSWORD_BCRYPT, $options)."\n";
// $2y$11$mrblnrK01GWt4g55.Z8Zs.1RslouNzBqCVW826QfBEuaRaVyq96c2

?>

我可以将mrblnrK01GWt4g55.Z8Zs.1RslouNzBqCVW826QfBEuaRaVyq96c2 部分存储在数据库中

要根据现有哈希验证用户提供的密码，我可以使用以下函数：

<?php
// Query the db to get $hash.
$hash = 'mrblnrK01GWt4g55.Z8Zs.1RslouNzBqCVW826QfBEuaRaVyq96c2';
$hash = '$2y$11$'.$hash;

if (password_verify('akki', $hash)) {
    echo 'Password is valid!';
} else {
    echo 'Invalid password.';
}
?>

我发现了一个类似的问题here，但它没有说明为什么显示算法（和成本）不是风险，尽管我理解为什么显示盐不是问题。此外，当我尝试更改算法或成本时，这可能会有所帮助的原因似乎不值得冒险。

Answer 1

为什么展示算法（和成本）不是风险

因为暴力破解仍然几乎是不可能的。风险没有有意义的增加。即使知道使用的算法和成本，每个密码也需要很多 很多 年。

您不存储该信息所做的唯一一件事就是使升级算法变得更加困难和/或在以后增加成本。随着更强大的硬件、新的攻击方法和更强大的算法等东西开始发挥作用，这些东西需要升级。

对于大多数用途而言，实用的做法是将计算单个哈希所需的时间保持在 0.3-0.5 秒左右。

您所做的任何使升级和重新散列变得更加困难的事情都会降低发生这种情况的可能性。这就是引入风险的原因。

---

当有效的攻击途径针对您使用的哈希函数时，您会怎么做？

这不是理论上的。在 GPU 加速攻击出现之前，很多人都对 SHA1 非常满意。

如果您要存储整个字符串，则在用户登录时通过password_needs_rehash() 运行它并根据需要重新设置密码是很简单的。

如果您已分离算法和选项指标并对其进行硬编码 - 您将如何升级*？只是更改它们意味着没有旧哈希的人可以登录。并且您无法生成新的哈希直到用户登录，因此您需要在某处维护算法+选项到哈希的映射。 ..

类似于数据库的地方。

存储整个字符串。

---

_{* 如果您不升级，而是通过默默无闻地依赖安全性，那么攻击者只需确定您使用一次的方法，就可以立即打开所有内容.我什至不会将其视为一种选择。}