这篇富有洞察力的文章提出密码不需要非常安全： http://www.baekdal.com/tips/password-security-usability？
我觉得这里面有一行特别令人困扰：
实际数字有所不同，但大多数 Web 应用程序每秒无法处理超过 100 个登录请求。
大多数 Web 应用程序真的只需要能够防御每秒 100 次攻击吗？当您处理可能受到多个入侵者攻击的分布式系统时，这个数字似乎很低。
编辑 进一步澄清我的问题：基于大多数 Web 服务器的当前平均性能，暴力攻击期间可能的最大登录尝试次数是多少？我问的不是离线密码攻击，因为有人真的可以大量尝试登录。
从角度来看，假设您需要一个不能使用 tar-pitting 或临时帐户禁用的系统（为了防止黑客通过登录尝试进行 DoS），那么基于 Web 的系统每秒实际登录尝试次数非常有用。
答案1
但大多数 Web 应用程序每秒无法处理超过 100 个登录请求。
这意味着：该文章的作者提出了一个未经证实的（但并非完全不合理的）主张：每秒发送超过 100 次登录将对“大多数” Web 应用程序造成有效的拒绝服务攻击。
对于每次登录，典型的 Web 应用必须对密码进行哈希处理，并将其与数据库中的哈希表示进行比较。如果 Web 应用使用一个好的哈希函数，这确实会占用相当多的 CPU。因此，这种说法可能并非完全不合理，但根据我的经验，大多数 Web 应用程序只使用简单的哈希算法，如 MD5、SHA1 或 SHA256，这些算法并不占用大量 CPU。
该文章的最大错误在于：
注意：以下示例基于每秒 100 个密码请求。
在接下来的几段中，作者根据每秒 100 次尝试的最大攻击率提出了密码强度的建议。对于在线的攻击，攻击者连接到实时的 Web 应用程序。
但对于离线攻击，攻击者首先通过 SQL 注入攻击下载了整个数据库，这是完全错误的。例如，这是一个SHA1 的 NVIDIA CUDA 实现，可以做到每秒 4700 万次哈希在小型服务器集群上。
Web 应用程序每秒仅需要能够防御 100 次尝试？
抱歉，您误解了这部分。现在，你从 Web 应用程序所有者的角度来看待这个问题保护反对在线的暴力密码猜测攻击。你应该采取行动长的在谈到这一点之前。
- 如果单个帐户的登录失败次数达到一定数量（3、5、10、25 都是合理的数字），则应暂时禁用该帐户。（或者更好的方法是，不要禁用帐户，而是减慢登录尝试速度，即缓降/速率限制。）
- 如果系统范围内每秒有数百次登录尝试失败，那么您的日志记录/监控框架（Nagios 等）应该向您发出警报，以便您意识到攻击。
最后，你可能想读与文章相关的常见问题解答，这让作者的意思更加清晰。他谈论的是最终用户如何生成合理安全且易于记忆的密码——而不是服务器端对密码的处理。
问题编辑后更新：
根据大多数 Web 服务器的当前平均性能，在暴力攻击期间可能的最大登录尝试次数是多少？
对于像 SHA1 这样的简单哈希，我认为一台四核服务器（假设编程技术良好）可以处理每秒大约 10,000 个请求。这完全取决于所使用的 Web 应用程序框架和编程，因为 HTTP 连接处理开销将超过 SHA1 计算速度。如果我们在 Prefork 模式下使用 Apache 和 fx PHP，那么数字会少得多，每台服务器每秒可能处理 2,000 个请求。
假设你有一个系统需求，不能使用 tar-pitting 或临时账户禁用
然后改变要求——这已经无法修复了。
基于网络的系统每秒实际登录尝试的次数非常有用。
再次强调，你应该有警报，当暴力攻击发生时，它会通知你长的在它变得如此大规模之前。
答案2
我们如何回答有关“大多数” Web 应用程序的问题？首先，大多数可能位于公司内部网中，但当您使用在 2 台以上服务器上运行的 Web 应用程序时，您可能已经超出了“大多数”的范围。
无论如何，我不认为它说你每秒只会收到 100 个请求，所以这就是你需要防御的全部，这就是你的问题听起来的样子，而是你可能每秒只能处理 100 个请求（即每分钟 60,000 个）所以这个级别是一个很好的权衡。
如果您的应用程序每秒可以处理 1000 次登录，也许您需要重新考虑。
这篇文章没有提到 tar-pitting，这是一种减慢登录回复速度的做法，因此暴力破解变得不可能 - 您可能亲眼见过这种情况，您尝试登录 5 次，之后每次输入密码时，它都会在那里等待很长时间才告诉您失败，并且 10 次尝试后延迟会变得更大。继续尝试，它继续变慢，但离开并在 20 分钟后回来，它又很快了。
这样做可以使暴力破解几乎不可能。
答案3
这篇文章的作者对“普通”网络应用程序可以处理的请求数量做了巨大的假设。如果你的网站位于一个代码编写良好的专用服务器上，那么它很可能能够轻而易举地每秒处理 1,000 个请求。一台没有任何优化的旧服务器可能只能每秒处理 10 个请求，然后就会开始停滞不前。作者必须选择一个数字作为计算的基础，而 100 似乎是一个合理的起点。
如果您试图防御暴力攻击或字典攻击，您可以使用各种技术，例如 TessellatingHeckler 提到的 tar-pitting，或者按照文章的建议对帐户进行临时锁定。我甚至见过系统会简单地忽略它发现的任何 IP 发送的请求，只要这些 IP 的请求速率超过一定速率。
至于最初的问题，攻击者希望能够在不导致服务器瘫痪的情况下尝试尽可能多的密码，因此您不需要能够“防御”每秒特定数量的请求，因为如果攻击者发现这会导致服务器速度变慢，他们会对自己的工具进行速率限制，因为不引起注意才是他们的最佳利益所在。只需设计您的应用程序，使其能够处理预期的正常负载以及一些合理的增长余地和偶尔的流量高峰。
如果您担心一般的 DDoS 攻击，那就完全是另一回事了，与每秒的密码尝试请求数无关。
答案4
您可以轻松监禁暴力破解者。假设在 3 次登录失败后，您将阻止来自该 IP 的登录 1 分钟（或更长时间），但继续向客户端发送用户/密码不匹配信息
另一种方法是将用户和管理员登录分开。比如，你正在制作一些用于用户登录的主表单，并在其附近放置用于管理员登录的假按钮，该按钮总是会显示“密码错误”。并为真正的管理员登录制作一些隐藏的网页：D