Dropbox密码安全

Question

Dropbox最近发布了Dropbox如何安全地存储您的密码

这真的比使用复杂的11或12的bcrypt更安全吗？

密码“链”作为其最弱的部分是安全的，那么在其中添加额外的2部分有意义吗？

据我所知，Global " pepper“意味着DB转储保护哈希，直到找到该哈希，然后每个用户仍然对每个哈希进行咸化，但是，如果DB泄漏只需对每个用户进行bcrypting，那么这会在多大程度上减缓逆转密码的速度呢？

Answer 1

这真的比使用复杂的11或12的bcrypt更安全吗？

那得看情况。显然，如果您考虑到他们服务器上的所有漏洞，这并不比为密码哈希方案(PHS)使用更高的工作负载更安全。如果您认为他们能够比密码数据库更好地保护他们的胡椒，那么密码就无法从转储中恢复。

密码“链”是安全的，因为它的最弱部分，所以是否有任何点添加额外的两个部分？

在这里，链条并不是真正正确的类比。假设攻击者可以残忍地使用无穷无尽的bcrypt哈希，但不能得到胡椒。这样的攻击者不可能恢复密码，因为他无法获得暴力强制密码所需的散列。

一个更好的类比应该是洋葱。如果不遍历所有的层(胡椒层、bcrypt层、SHA-512层)，就无法访问核心(密码)。

据我所知，Global " pepper“意味着DB转储保护哈希，直到找到该哈希，然后每个用户仍然对每个哈希进行咸化，但是，如果DB泄漏只需对每个用户进行bcrypting，那么这会在多大程度上减缓逆转密码的速度呢？

胡椒是256位的AES密钥。如果攻击者没有掌握此他们不可能恢复哈希，因此可能无法获得密码。然而，一旦您已经取出密钥，附加的AES加密只会对强制密钥所需的运行时间产生大约0的影响。所以你赢了，万一你能保护钥匙，如果你做不到的话，你什么都不会失去。

Answer 2

据我所知，Global " pepper“意味着DB转储保护哈希，直到找到该哈希，然后每个用户仍然对每个哈希进行咸化，但是，如果DB泄漏只需对每个用户进行bcrypting，那么这会在多大程度上减缓逆转密码的速度呢？

如果您使用带有随机128位密钥(最小密钥大小)的AES，则获取加密哈希而不是密钥的攻击者实际上已经死在了他们的轨道上。对AES进行暴力攻击在实践中是不可能的。

这真的比使用复杂的11或12的bcrypt更安全吗？密码“链”作为其最弱的部分是安全的，那么在其中添加额外的2部分有意义吗？

与其像你那样一般地问“它是否更安全”，我们还需要更具体地问：

1. 有什么情况是它保护的，而不是隐秘的呢？
2. 这些场景是否有足够的风险，值得增加复杂性？

特别是，使用额外的加密步骤可以防止攻击者设法获取加密的加扰密码而不是加密密钥的情况。如果攻击者两者兼得，那么它什么也不做。

因此，它只在防御者能够成功地安排满足该条件的场景中提供额外的安全性。有一些似乎符合这一描述的情景：

• 攻击者通过对前端web应用程序执行SQL注入或类似攻击来获取加密密码散列，但加密密钥未存储在条目所在的RDBMs中。
• 攻击者可以访问具有所有密码条目的主机，但此类主机从未包含加密密钥。

后一种情况可以通过让硬件安全模块或特殊的、经过增强的服务器(例如，中转后端 in 哈希科普(氏)地窖)成为加密密钥的唯一所有者来安排，这样拥有密码数据库的其他服务器只能通过将密文发送给该专用密钥所有者来对密码条目进行加密或解密。但是，这需要额外的成本和精力来获得、开发、硬化和/或配置；这将成为一个额外的失败点，能够使整个系统崩溃。

那么，它值得付出额外的努力和复杂性吗？这是一个判断力。

Answer 3

现有的答案涵盖了加密步骤在不同场景中的有用性，但还没有人提到哈希步骤。

which ( bcrypt所基于的)要求最大密钥长度为448位，以确保扩展密钥的每一位都依赖于用户密钥的每一位(密码)。虽然大多数bcrypt实现都乐于接受较长的密钥，但只有前576位才能完全影响输出。

在某些情况下，这可能相当重要。想象一下使用1024位/ 128字节密码，它每字节只有1位熵；密码本身有128位熵。但是，使用带此密码的bcrypt作为密钥可以达到56到72位的有效强度。这显然不可取。

使用SHA-512对密码进行散列并为bcrypt获取密钥意味着(非扩展的)密钥的每一位都依赖于密码的所有位，所以扩展密钥的哪一部分取决于密钥的哪些部分不再重要。这意味着密码可以任意长而不降低安全性。