在Argon2哈希中存储参数作为潜在的安全问题？

Question

我真的在努力确保在密码存储方面遵循最佳实践，在寻找了一个好的算法之后，我发现Argon2是“下一个大问题”。我一直在VB.Net中使用Liphsoft (Liphsoft.Crypto.Argon2)提供的NuGet包测试它。

默认情况下，哈希算法的参数存储在哈希本身中。我理解(或者至少我认为我知道)，如果您决定更改参数，这将使您更容易将其迁移到新的哈希。

我的问题是，它是否通过在哈希本身中提供哈希算法的参数来降低安全性？我目前正在考虑的只是修剪掉这些信息，并将参数值隐藏在代码中，这样如果有人掌握了哈希，他们就无法立即看到“哦，他们使用的是带有这些特定参数的Argon2”。我应该关心这个吗？

任何反馈都是非常感谢的。谢谢!

在发帖之前，我也看过这个问题：Argon2输出长度和参数存储？

Answer 1

首先，在密码学的世界里，遵循“下一件大事”通常不是一个好主意。与新代码和算法相比，您更喜欢经过战斗测试的代码和算法。在这种特殊情况下，人们普遍认为，Argon2极不可能成为攻击的牺牲品，这些攻击在实践中会使情况恶化，而不是氪星、bcrypt或PBKDF2，所以选择Argon2并不一定是错误的；只要考虑到，当涉及密码学时，你的直觉应该会驱使你走向更成熟、更保守的选择。您还应该更喜欢现成的算法和实现，而不是您已经对其进行了自定义修改的版本；您更有可能通过误解或bug使事情变得更弱，而不是为了充分解决真正的弱点。可以这样想:如果你的关注点是基于真实的东西，而且它们像你相信的那样容易解决，那么密码学家和密码库的作者就已经为你处理好了。

其次，需要参数来重新计算哈希。如果在初始哈希密码时指定不同的硬度约束，则会得到不同的结果。因此，如果您在验证哈希时不知道这些参数，则必须尝试这些参数的每个组合，直到幸运地发现结果时，如果您将这些参数直接存储在代码中，则技术上不需要将它们与散列本身一起保存。然而，这些参数不应该是一成不变的:当内存变得更便宜，硬件变得更快时，它们应该不断地增加。有些库允许您在第一次实例化库时通过“校准”计算来动态地完成这一任务，这样它就使用了一些可用内存，并且占用了(例如) 0.1s的CPU时间。

以失去这种灵活性为交换条件，您在安全性方面获得了相对较小的好处。如果您以合理的成本(> 0.1s)使用Argon2，那么除了最琐碎的密码之外，攻击者还需要花费不太实际的时间来恢复所有密码；在一个由10,000个用户组成的数据库中运行最常见的1000个密码列表将花费10天以上的CPU时间，即使在这里，您也可以通过阻止用户从这些列表中使用密码来减轻这一点。

尽管如此，还是有一个不可否认的，即使是小的好处。我们能在没有不利影响的情况下获得这种好处吗？是。与其隐藏成本参数(这并不构成熵的多少)，不如在将密码发送到Argon2之前先计算密码的HMAC。通过使用密钥和首先计算HMAC，您可以保持成本变量的灵活性，但也可以防止攻击者有任何能力测试密码，除非他们还获得了HMAC秘密，而HMAC秘密的熵要比成本参数大得多。

编辑:另一件要注意的事情是，你的建议并没有你想的那么多。正如我在评论@LuisCabrillo的答案时指出的那样，这些东西的总和可能是16位熵。针对一个在您的站点上使用他们已经知道的密码在您的站点上创建帐户的聪明攻击者，您现在几乎没有阻止他们:他们知道密码和匹配的哈希，所以只需要对每种可能性进行一次分析，直到他们确定您的算法和成本因素。然后他们可以像往常一样攻击你的密码数据库。