基于每秒100次尝试的Web服务器最低密码安全性

这篇有见地的文章建议密码不必非常安全：http : //www.baekdal.com/tips/password-security-usability？

我在这里发现一条令人困扰的特定行：

实际数量有所不同，但是大多数Web应用程序每秒将无法处理100个以上的登录请求。

确实，大多数Web应用程序仅需要能够防止每秒100次尝试吗？当您处理可被多个入侵者攻击的分布式系统时，数量似乎很少。

编辑 关于我的问题的更多说明：根据大多数Web服务器的当前平均性能，在暴力攻击期间最大可能的登录尝试次数是多少？我不是在问离线密码攻击，因为有人可以真正发起登录尝试。

放眼来看，假设您有一个无法使用tar-pitting或临时帐户禁用（以防止黑客通过登录尝试进行DoS攻击）的系统，即基于Web的系统每秒的实际登录尝试次数非常有用

但是大多数Web应用程序每秒无法处理100个以上的登录请求。

这意味着什么：该文章的作者提出了未经证实（但并非完全不合理）的主张，即每秒发送100个以上的登录将是对“大多数” Web应用程序的有效拒绝服务攻击。

对于每次登录，典型的Web应用程序都必须对密码进行哈希处理，并将其与数据库中的哈希表示形式进行比较。如果webapp使用良好的哈希函数，则确实会使用大量CPU。因此，这种说法可能并不完全不合理，但是以我的经验，大多数Web应用程序仅使用MD5，SHA1或SHA256之类的简单哈希，这些哈希并不占用大量CPU。

那篇文章的最大错误出现在这里：

注意：以下示例基于每秒100个密码请求。

在下几段中，作者基于每秒100次尝试的最大攻击率，提出密码强度建议。对于攻击者连接到实时Web应用程序的在线攻击而言，这可能是一个合理的数字。

但是对于离线攻击而言，攻击者首先通过fx SQL注入攻击下载了整个数据库，这是完全错误的。例如，这是SHA1的NVIDIA CUDA实现，在小型服务器群集上每秒可完成4700万次哈希处理。

Web应用程序仅需要能够防止每秒100次尝试？

抱歉，但是不对，您误会了这一部分。现在，你从Web应用程序所有者的角度看它试图保护针对在线强力密码猜测攻击。你应该采取的行动很长谈到这个之前。

1. 如果单个帐户有一定数量的失败登录尝试（3,5,10,25可以都是合理的数目），则应暂时禁用该帐户。（或者更好的做法是，不要禁用该帐户，而要减慢登录尝试的速度，也就是限制/限制速率。）
2. 如果您每秒在整个系统范围内遇到数百次失败的登录尝试，则您的日志记录/监视框架（Nagios等）应向您发出警报，以使您意识到攻击的发生。

最后，您可能想阅读本文附带的FAQ，它使作者的意思更加清楚。他谈论的是最终用户如何生成合理的安全且仍然容易记住的密码-而不是服务器端的密码处理。

在问题编辑后更新：

根据大多数Web服务器的当前平均性能，在暴力攻击期间最大可能的登录尝试次数是多少？

对于像SHA1这样的简单哈希，我想说一台四核服务器，假设使用良好的编程技术，就可以应付每秒10,000个请求的非常粗糙的状况。这将完全取决于所使用的webapp框架和编程，因为HTTP连接处理开销将超过SHA1计算速度。如果我们在Prefork模式下将Apache与fx PHP一起使用，那么这个数字将非常吸引人，每台服务器每秒可能有2,000个请求。

假设您有一个无法使用tar-pitting或禁用临时帐户的系统的要求

然后更改需求-无法修复。

基于Web的系统上每秒的实际登录尝试次数非常有用。

同样，您应该具有警报功能，可以在蛮力攻击发生很久之前就将其通知您。

我们如何回答有关“大多数” Web应用程序的问题？首先，大多数服务器可能都位于公司的Intranet上，但是当您访问在2台以上服务器上运行的Web应用程序时，您可能已经“脱颖而出”。

无论如何，我认为它不会说您每秒仅会收到100个请求，因此您需要防御的就是这一切，这就是您的问题的声音，但您每秒可能只能处理100个请求（即60,000 /分钟），这样就可以很好地权衡。

如果您的应用程序每秒可以处理1000次登录，则可能需要重新考虑。

本文没有提及tar-pitting，这是减慢登录响应速度的一种做法，因此无法进行强行强制-您可能会在尝试登录5次后亲自看到该密码，然后每次键入密码都位于该位置在告诉您失败之前要花很多时间，经过10次尝试后，延迟会变得更大。继续尝试，它会一直变慢，但是离开并在20分钟后回来，它又很快了。

这样做会使暴力破解几乎成为不可能。

该文章的作者对“常规” Web应用程序可以处理的请求数量做出了巨大的假设。如果您的站点位于具有编写良好代码的专用服务器上，则它很可能每秒可以处理1,000个请求而不会费力。没有任何优化的旧服务器可能只能每秒处理10个请求，然后再开始停止。作者必须选择一个数字作为他的计算基础，而100似乎是一个合理的起点。

如果要防御暴力攻击或字典攻击，则可以使用各种技术，例如TessellatingHeckler提到的tar-pitting，或按照本文的建议在帐户上设置临时锁定。我什至看到系统会忽略来自任何IP的请求，因为这些IP看到的发送请求超过一定速率。

对于最初的问题，攻击者将希望能够尝试尽可能多的密码，同时又不会使服务器停机，因此并不是说您需要每秒“防御”特定数量的请求，因为如果攻击者看到自己的工具导致服务器运行速度降低，他们将对自己的工具进行速率限制，因为不引起人们的注意是他们的最大利益。只需将应用程序设计为能够处理预期的正常负载，再加上一些合理的增长余量和偶尔的流量高峰。

如果您担心通用的DDoS攻击，那完全是另一回事，并且与每秒尝试输入密码的请求无关。

您可以对暴力分子实施简易监禁。假设3次登录失败后，您阻止该IP的登录时间为1（或更多）分钟（a），但只是继续发送给客户端用户/密码不匹配

另一种方法是分隔用户和管理员登录名。例如，您正在为用户登录建立一些主要形式，并在其旁边放置用于管理员登录的伪造按钮，女巫总是会说“密码不正确”。并制作一些隐藏的网页进行真正的管理员登录：D