真的比使用11或12复杂度的bcrypt更安全吗？它最薄弱的部分，因此在任何地方添加额外的2部分是否有意义？仍会为每个用户添加盐分，但如果DB泄漏而不是简单地对密码进行加密，那么使人们扭转密码的速度减慢了多少？
#1 楼
这真的比使用复杂度为11
这取决于。显然，如果您认为他们服务器上的所有内容都受到了损害，这并不比使用更高的密码散列方案（PHS）工作量安全。如果您假设他们可以比其密码数据库更好地保护自己的Pepper，那么密码就无法从转储中恢复。
密码“链”是安全性最弱的部分，因此，
要在链中添加多余的2个部分，这实际上不是正确的类比。假设攻击者可以无限次暴力破解许多bcrypt散列，但无法获得好处。这样的攻击者无法恢复密码，因为他无法获得暴力破解所需的哈希。
更好的类比是洋葱。如果没有遍历所有层（pepper，bcrypt，SHA-512），您就无法进入核心（密码）。
我知道全局“ pepper”意味着数据库转储会保护哈希，直到找到该哈希为止，然后每个用户的哈希值仍会被盐化，但是如果出现以下情况，这会减慢人们反向密码的速度DB泄漏只是简单地将它们加密？
Pepper是256位AES密钥。如果攻击者不了解这一点，他们将无法恢复哈希值，因此也可能无法获得密码。但是，一旦您窃取了密钥，则额外的AES加密对暴力破解密钥所需的运行时间几乎只有0影响。因此，如果您可以保护钥匙，那么您会赢，如果您不能这样做，则不会损失任何东西。
评论
$ \ begingroup $
+表示不是链条，而是洋葱。当我阅读问题时，我想到了这一点。
$ \ endgroup $
–马雷克
16 Dec 20'在11:29
$ \ begingroup $
那不是胡椒，是吗？散列前必须添加胡椒。此外，它说的是“使用全球Pepper进行AES256加密”，而不是“ as”。
$ \ endgroup $
–UTF-8
16 Dec 20'在15:19
$ \ begingroup $
@ UTF-8 Pepper是一个秘密值，在哈希密码的过程中以某种方式使用它。可以像此处通过加密，HMAC加密或简单地在密码前加上PHS固有的内容来完成此操作。
$ \ endgroup $
– SEJPM♦
16 Dec 20'在16:55
$ \ begingroup $
我是唯一读过Orge的人吗？
$ \ endgroup $
–牛羚
16 Dec 20'在17:21
#2 楼
我了解到全局“胡椒粉”意味着数据库转储会保护散列，直到找到该胡椒为止，然后每个用户仍对每个散列加盐，但是这会减慢人们在回退密码时的速度DB泄漏只是简单地将其加密？
如果您将AES与随机的128位密钥（最小的密钥大小）一起使用，则攻击者将获得加密的哈希值，而不是密钥实际上已经死了。在实践中不可能对AES进行暴力攻击。
这真的比使用11或12复杂度的bcrypt更安全吗？密码“链”的最薄弱部分是安全的，因此，在您的身上是否总要问“是否更安全”，是否有必要在？
中添加额外的2个部分？确实，我们需要具体说明一下：
是否存在防止bcrypt不能保护的任何情况？值得增加额外的复杂性吗？
，特别是使用附加的加密步骤可以防止攻击者设法获取加密的加扰密码而不是加密密钥的情况。如果攻击者同时获得了两者，那么它什么也不会做。
因此，它仅在防御者可以成功地满足该条件的情况下提供额外的安全性。有一些符合该描述的合理方案：攻击者通过对前端Web应用程序执行SQL注入或类似攻击来获取加密的密码哈希，但是
攻击者可以访问具有所有密码条目的主机，但没有这样的主机包含加密密钥。
可以通过让硬件安全模块或特殊的加固服务器（例如Hashicorp的Vault中的Transit后端）作为加密密钥的唯一所有者来安排后一种情况，以便拥有密码数据库的其他服务器只能通过将密文发送给专门的密钥所有者来对它们进行加密或解密。但是，这需要额外的成本和精力来获取，开发，强化和/或配置；这就成为了一个额外的故障点，能够使整个系统瘫痪。
那么值得付出额外的努力和复杂性吗？那是个判断电话。
#3 楼
现有答案涵盖了在不同情况下加密步骤的有用性，但没有人提到哈希步骤。Blowfish（bcrypt所基于的）要求最大密钥长度为448位，以确保扩展密钥的每一位都取决于用户密钥（密码）的每一位。尽管大多数bcrypt实现愉快地接受更长的密钥，但是只有前576位会完全影响输出。
在某些情况下，这可能非常重要。想象一下使用1024位/ 128字节密码，该密码每个字节只有1位熵。密码本身具有128位的熵。但是，使用带有该密码的bcrypt作为密钥可以实现56到72位的有效强度。显然这是不可取的。
使用SHA-512哈希密码并获取bcrypt的密钥意味着（未扩展）密钥的每一位都已经取决于密码的所有位，因此扩展密钥的哪些部分取决于密钥的哪些部分不再重要。这意味着密码可以任意长，而不会降低安全性。
评论
如果存储全局胡椒粉的HSM足够安全，并且不能从胡椒粉中导出（它是在HSM内部生成的，并且永远不会离开它），那么可能的攻击者将无法将所有散列在一起。他将被迫使用HSM的服务逐一解密哈希，并且可能会受到一些限制，例如每个时间段的最大哈希解密数。 ---或者，可以在HSM中完全检查密码，这样就永远不会对哈希进行未经加密的公开，但我认为，如此强大的HSM集群将太昂贵。