这里有两个重要的风险类别：

1. 对实时系统的攻击（例如猜测用户密码）
2. 对离线密码哈希的攻击（例如来自数据库转储）

第一种类型的攻击可以分为不同的子类别：

• 对用户密码的暴力攻击。
• 猜测一个用户帐户上最常用的 1000 个密码。
• 猜测 1000 个用户帐户中最常用的前 3 个密码。

密码复杂性要求在很大程度上解决了最后两个类别，并使蛮力式攻击更加困难。当与适当的速率限制相结合时，所有三个类别都可以有效地变得不可行。传统上，“实时系统”攻击是更强密码要求的主要驱动力。

第二种类型的攻击通常发生在您的服务器被入侵之后。尽管每个人都有最好的意图和努力，但网站和服务器确实会遭到黑客攻击。您无法保护自己免受所有可能的攻击媒介的侵害，而这是安全世界中的既定事实。你会在某个时候被黑客入侵。

数据库转储被盗存在三个主要问题：

• 私人用户数据被泄露，通常由个人信息组成。
• 用户密码以纯文本（如果您没有做好自己的工作！）或散列形式泄露。
• 用户在不同的服务中重复使用密码。

您无法阻止私人用户数据泄露。尝试可逆地加密或混淆数据库中的数据只会导致代码中出现一层复杂的抽象，并且几乎没有或根本没有提供安全优势。您可以做的最好的事情是对您的产品、服务和基础设施进行严格的质量保证测试和安全测试，以最大程度地降低数据被盗的风险。

但是，您可以保护用户的密码。通过使用单向加密函数对密码进行哈希处理，我们可以使攻击者难以发现原始的纯文本密码。

仅使用 MD5 或 SHA1 的标准技术被发现存在缺陷，因为可以提前预先计算大型数据库（称为彩虹表），从而允许攻击者在表中查找哈希值并找到其对应的纯文本密码. 这种技术是使用盐来对抗的，盐的目的是通过引入每个用户唯一的随机值来使每个哈希对用户都是唯一的，这使得彩虹表不可行。攻击者后来发现，GPU 可以使用 OpenCL 和 CUDA 等技术以高度并行的方式计算哈希函数。攻击者现在可以在 GPU 上每秒计算数十亿个哈希，或者在 GPU 集群上每秒计算数千亿个哈希，而不是 CPU 上每秒几百万个哈希，所有这些都只利用现成的消费硬件，并且可以自由使用可用的软件。sha256(pass+salt)哈希类型不再安全。另一种方法是设计速度较慢的密钥派生算法，例如 PBKDF2 或 bcrypt。这些在 GPU 等并行设备上更难计算，并且将每秒的计算次数减少到使完全暴力破解不可行的水平。但是，字典攻击仍然是合理可行的，尤其是在使用通用密码的情况下。

所以，总而言之：不，我不认为我们过于重视密码复杂性要求。所涉及的攻击向量很复杂，而且当今人们可用的计算能力足以使普通密码变得危险，无论密钥派生函数有多慢和计算成本多高。用户重复使用密码，因此我们必须尽可能保护这些密码。

请记住，我们还需要复杂密码的原因之一是，当数据库被黑客入侵时，密码不能轻易被暴力破解。（不太复杂的密码将允许这样做）

虽然用户永远不应该重复使用他们的密码，但不幸的是，这种情况仍然会发生。

延迟或尝试计数器将阻止直接的暴力攻击，但如果黑客窃取了您的整个数据库怎么办？然后，他可以根据需要暴力破解您的密码。有了这个，你的双因素身份验证已经被破坏了 50%。您的第二个身份验证步骤可能会被社会工程/计算机病毒或任何其他需要的技术破坏。

不，在我看来，我们显然没有过多地关注密码复杂性，而不是在这一点上。当服务器上的其他所有内容都受到损害时，您的强哈希（可能）不会受到影响。

对复杂性要求的主要关注是难以对泄露的哈希表进行离线攻击。不重用密码比密码复杂性要重要得多，如果数据库没有受到破坏并且适当的暴力预防措施到位，那么从实时系统的安全角度来看，任何重要的密码都可以。

但是，由于密码经常被重复使用，而且我们不一定知道哈希表是否已被泄露，因此需要复杂性来保护其他帐户或未实现的哈希表泄露，以免攻击者确定您的密码。

但就我个人而言，我倾向于同意某些地方（不是大多数地方，而是一些地方）已经开始达到另一个危险的一面，这使得复杂性要求变得如此困难，以至于它降低了可用性并导致用户感到沮丧，这对关卡来说太严重了相关站点所需的安全性。对于过去曾被入侵并试图“做得更好”的网站来说尤其如此。（索尼，我在看你的方向。）