这篇富有洞察力的文章提出，密码不需要非常安全： http : //www.baekdal.com/tips/password-security-usability ？
在这里有一个特定的线，我觉得很麻烦：
实际数量会有所不同，但大多数Web应用程序将无法处理每秒100多个login请求。
大多数Web应用程序是否只需要能够保护每秒100次就可以？ 当处理可能受到多个入侵者攻击的分布式系统时，似乎非常低。
编辑更多关于我的问题的解释：根据大多数Web服务器的当前平均性能，在暴力攻击期间可能的最大login尝试次数是多less？ 我不是在询问离线密码攻击，有人可以真正发起login尝试。
换个angular度来说，假设你有一个系统不能使用标准或临时帐户禁用的要求（为了防止黑客通过login尝试进入DoS），一个基于Web的系统每秒的实际login尝试次数是非常有用的。
但是大多数Web应用程序将无法处理每秒100多个login请求。
这意味着什么：这篇文章的作者提出了一个没有根据的（但不是完全不合理的）声明，即每秒发送超过100个签名将是对“大多数”web应用程序的有效拒绝服务攻击。
对于每个login，典型的Web应用程序将不得不散列密码，并将其与数据库中的散列表示进行比较。 如果Web应用程序使用良好的散列函数 ，则确实会使用相当数量的CPU。 所以这个说法可能不是完全不合理的，但是根据我的经验，大多数webapps只是使用一个简单的哈希，如MD5，SHA1或SHA256，这不是CPU密集型的。
那篇文章中的大错误来自这里：
注意：下面的示例基于每秒100个密码请求。
在接下来的段落中，作者根据每秒100次尝试的最大攻击速度提出密码强度的build议。 对于攻击者连接到实时Web应用程序的在线攻击，这可能是一个合理的数字。
但是对于一个在线攻击，攻击者首先通过一个SQL注入攻击下载了整个数据库，这完全是错误的。 例如，下面是一个针对SHA1的NVIDIA CUDA实现 ，它可以在一个小型服务器集群上每秒处理4700万次哈希 。
Web应用程序只需要能够保护每秒100次尝试？
对不起，但不是，你误解了这部分。 现在你从Web应用程序所有者的angular度来看待它，试图防止 在线暴力密码猜测攻击。 在这之前，你应该采取行动很久 。
最后，您可能想阅读文章中的常见问题解答 ，这使作者的意思更清晰。 他在谈论最终用户如何能够产生合理的安全性并且仍然容易记住密码 – 而不是关于服务器端密码的处理。
在问题编辑之后更新：
根据大多数Web服务器的当前平均性能，在暴力攻击期间可能的最大login尝试次数是多less？
对于像SHA1这样的简单散列，我假设一个四核服务器假设编程技术很好，可以在每秒10000个请求的粗略处理中进行处理。 这完全取决于所使用的webapp框架和编程，因为HTTP连接处理开销将主宰SHA1的计算速度。 如果我们在使用fx PHP的Prefork模式下使用Apache，那么这个数字将会是非常的情人，每个服务器每秒可能有2,000个请求。
假设你有一个系统不能使用tar-pitting或临时帐户禁用的要求
然后改变要求 – 那是无法修复的。
在基于networking的系统上每秒实际的login尝试次数是非常有用的。
再次，你应该有警觉，通知你一个暴力攻击很久之前，它得到这个巨大的。
我们如何回答关于“大多数”Web应用程序的事情？ 大多数情况下可能在公司内部网上，一开始，当你到达在2台服务器上运行的networking应用程序的时候，你可能是“最”的。
无论如何，我认为它不会说你每秒只能获得100个请求，这就是你需要防范的一切，这就是你的问题的答案，而你可能每秒只能处理100个请求（这是60,000 /分钟），这样的水平，使得一个很好的折衷。
如果您的应用程序可以处理每秒1000次login，那么可能需要重新考虑一下。
这篇文章没有提到tar-pitting，这是放慢login回复的做法，所以暴力破解变得不可能 – 你可能已经看到了它自己，你尝试login5次，然后每次你input一个密码，它就坐在那里在告诉你失败之前搅动很久，在10次尝试之后，延迟变得更大。 继续尝试，并保持减速，但离开并在二十分钟内回来，它又快了。
这样做可能使暴徒强迫几乎不可能。
该文章的作者正在对“正常”Web应用程序可以处理的请求数量做出巨大的假设。 如果您的站点位于专用服务器上，且代码编写良好，则可能每秒处理1,000个请求，而不会出现任何问题。 没有任何优化的旧服务器可能每秒只能处理10个请求，然后才开始停止。 作者不得不挑选一个数字作为他的计算依据，100似乎是一个合理的开始。
如果您试图抵御暴力或字典攻击，您可以像TessellatingHeckler提到的那样使用各种技术，例如tar-pitting，或者按照文章中的build议临时locking帐户。 我甚至看到系统会忽略来自任何IP的发送请求超过一定速率的请求。
至于原来的问题，攻击者希望能够尽可能多地尝试密码，而不要把服务器closures，所以并不是说你需要能够“防御”每秒的特定数量的请求，如果攻击者在服务器上看到导致服务器速度变慢的话，就会限制他们自己的工具，因为他们最关心的不是引起注意。 只要devise你的应用程序就能够处理你预期的正常负载加上一些合理的增长空间和偶尔的stream量高峰。
如果您担心通用的DDoS攻击，那完全是另一回事了，并且与密码尝试每秒的请求无关。
你可以为蛮力执行简单的监狱。 说3失败login后，你阻止从该IPlogin1（或更多）分钟（一），但只是继续发送到客户端用户名/密码错配
另一种方法是分离用户和pipe理员login。 说，你正在做一些用户login的主要forms，并把它附近的假buttonpipe理login女巫总是会说“Incorect密码”。 并为真正的pipe理员login做一些隐藏的网页：D