security - 最佳实践 : Salting & peppering passwords?

Question

我遇到了一个讨论，在讨论中我了解到我所做的实际上并不是对密码进行加盐处理，而是对它们进行加盐处理，从那时起我就开始使用以下功能进行这两项操作:

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

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

A 盐 是一个随机生成的值，通常与数据库中的字符串一起存储，旨在使使用哈希表无法破解密码。由于每个密码都有自己的盐，它们必须单独暴力破解才能破解；但是，由于 salt 与密码哈希一起存储在数据库中，因此数据库泄露意味着两者都丢失。

A 胡椒是与数据库分开存储的站点范围的静态值(通常在应用程序的源代码中硬编码)，旨在保密。使用它是为了使数据库的泄露不会导致整个应用程序的密码表被暴力破解。

有什么我遗漏的吗？对我的密码进行加盐和调味是保护用户安全的最佳选择吗？这样做是否有任何潜在的安全漏洞？

注意:为了讨论的目的，假设应用程序和数据库存储在不同的机器上，不共享密码等，因此数据库服务器的破坏并不自动意味着应用程序服务器的破坏。

Answer 1

行。看到我需要写这个 over和 over ，我将仅对胡椒做最后一个规范的回答。

辣椒的明显好处

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

这就是为什么这么多人认为辣椒是个好主意的原因。它“有道理”。

辣椒的现实

在安全和密码学领域，“有意义”是不够的。某些事情必须是可证明的 和 使其被认为是安全的。此外，它必须以可维护的方式实现。无法维护的最安全系统被认为是不安全的(因为如果该安全性的任何部分出现故障，整个系统就会崩溃)。

辣椒既不适合可证明的模型，也不适合可维护的模型......

辣椒的理论问题

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

将一个散列输入另一个可能是危险的。

在你的例子中，你做 hash_function($salt . hash_function($pepper . $password)) .

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

这就是为什么像 PBKDF2 这样的算法使用特殊操作将它们组合起来(在这种情况下为 hmac)。

关键是，虽然这不是什么大不了的事，但随便乱扔也不是一件小事。加密系统旨在避免“应该工​​作”的情况，而是专注于“设计工作”的情况。

虽然这可能看起来纯粹是理论上的，但实际上并非如此。例如，Bcrypt cannot accept arbitrary passwords .所以路过bcrypt(hash(pw), salt)确实可以导致比 bcrypt(pw, salt) 弱得多的哈希值如果 hash()返回一个二进制字符串。

反对设计

bcrypt(和其他密码散列算法)的设计方式是使用盐。胡椒的概念从未被引入。这可能看起来很琐碎，但事实并非如此。原因是盐不是 secret 。它只是一个攻击者可以知道的值。另一方面，根据定义，胡椒是一种加密 secret 。

当前的密码散列算法(bcrypt、pbkdf2 等)都被设计为只接受一个 secret 值(密码)。根本没有研究在算法中添加另一个 secret 。

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

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

复杂性是安全的敌人

信不信由你，Complexity Is The Enemy Of Security .制作一个看起来很复杂的算法可能是安全的，也可能不是。但是它不安全的可能性非常大。

辣椒的重大问题

不可维护

您对辣椒的实现排除了旋转辣椒键的能力。由于在单向函数的输入中使用了胡椒，因此您永远无法在值的生命周期内更改胡椒。这意味着你需要想出一些奇怪的技巧来让它支持 key 轮换。

这是极重要，因为每当您存储加密 secret 时都需要它。没有轮换 key 的机制(定期和在违规后)是一个巨大的安全漏洞。

而您当前的胡椒方法将要求每个用户要么通过轮换使他们的密码完全无效，要么等到他们下次登录时轮换(这可能永远不会)......

这基本上使您的方法立即无效。

它需要您推出自己的加密货币

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

Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break.

Bruce Schneier

从不 推出您自己的加密货币...
更好的方法

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

只使用现有的算法

如果您正确使用 bcrypt 或 scrypt(成本很高)，那么除了最弱的字典密码之外，所有密码都应该在统计上是安全的。以成本 5 对 bcrypt 进行散列的当前记录是每秒 71k 散列。按照这个速度，即使是 6 个字符的随 secret 码也需要数年时间才能破解。考虑到我的最低推荐成本是 10，这将每秒散列减少了 32 倍。所以我们只讨论每秒 2200 个散列。按照这个速度，即使是某些字典短语或修改也可能是安全的。

此外，我们应该在门口检查那些弱密码，不允许他们进入。随着密码破解变得越来越先进，密码质量要求也应该如此。这仍然是一个统计游戏，但是有了适当的存储技术和强密码，每个人都应该非常安全...

在存储之前加密输出哈希

在安全领域存在一种算法，旨在处理我们上面所说的一切。这是一个分组密码。这很好，因为它是可逆的，所以我们可以轮换 key (是的!可维护性!)。这很好，因为它是按设计使用的。这很好，因为它不给用户任何信息。

让我们再看看那条线。假设攻击者知道您的算法(这是安全所必需的，否则它是通过默默无闻的安全性)。使用传统的胡椒方法，攻击者可以创建哨兵密码，并且由于他知道盐和输出，他可以暴力破解胡椒。好吧，这是一个远景，但这是可能的。使用密码，攻击者一无所获。而且由于盐是随机的，哨兵密码甚至不会帮助他/她。所以他们剩下的最好的办法就是攻击加密形式。这意味着他们首先必须攻击您的加密散列以恢复加密 key ，然后再攻击散列。但是有一个 拍品 对密码攻击的研究，所以我们想依靠它。

TL/DR

不要用辣椒。它们有很多问题，有两种更好的方法:不使用任何服务器端 secret (是的，没关系)和在存储之前使用分组密码加密输出哈希。