http://www.baekdal.com/tips/password-security-usability？
这里有一条特定的线路让我觉得麻烦：
The actual number varies,but most web applications would not be capable of handling more than 100 sign-in requests per second.
是否真的大多数Web应用程序只需要能够防止每秒100次尝试？当您处理可能被多个入侵者攻击的分布式系统时,似乎数量非常低.
编辑
更多关于我的问题的澄清：
根据大多数Web服务器当前的平均性能,暴力攻击中可能的最大登录尝试次数是多少？我不是在询问有人可以真正做出登录尝试的脱机密码攻击.
从视角来看,假设您需要一个不能使用tar-pitting或临时帐户禁用的系统(为了防止黑客通过登录尝试进行DoS),基于Web的系统每秒实际登录尝试次数非常有用.
解决方法
but most web applications would not be capable of handling more than 100 sign-in requests per second.
这意味着：该文章的作者提出了一个未经证实(但并非完全不合理)的声明,即每秒发送超过100次登录将是对“大多数”Web应用程序的有效拒绝服务攻击.
对于每次登录,典型的webapp都必须对密码进行哈希处理,并将其与数据库中的哈希表示进行比较.如果webapp使用a good hashing function,这确实使用了相当数量的cpu.所以声明可能并非完全不合理,但根据我的经验,大多数webapps只使用像cpu5,SHA1或SHA256这样的简单散列,而不是cpu密集型.
Note: The examples below are based on 100 password request per second.
在接下来的段落中,作者根据每秒100次尝试的最大攻击率对密码强度提出建议.对于攻击者连接到实时Web应用程序的在线攻击,这可能是一个合理的数字.
但对于离线攻击,攻击者首先通过fx sql注入攻击下载整个数据库,这是完全错误的.例如,这是一个NVIDIA CUDA implementation for SHA1,它可以在小型服务器集群上每秒执行4700万次哈希.
web applications only need to be able to protect against 100 attempts per second?
对不起,但不,你误解了这一部分.现在你从webapp所有者的角度来看它,试图防止在线暴力密码猜测攻击.在此之前你应该采取行动.
>如果个人帐户有一定数量的失败登录尝试(3,5,10,25都可以是合理的数字),则应暂时禁用该帐户. (或者更好的是,不要禁用帐户,但要减慢登录尝试速度,a.k.a tarpitting / rate limits.)
>如果您在系统范围内每秒都有数百次失败的登录尝试,那么您的日志记录/监控框架(Nagios等)应该尖叫警报,以便您了解攻击.
最后,您可能想阅读FAQ that goes with the article,它使作者的意思更加清晰.他在谈论最终用户如何生成相当安全且易于记忆的密码 – 而不是服务器端密码处理.
编辑问题后更新：
Based on the current average performance of most web servers,what is the maximum number of login attempts possible during a brute force attack?
对于像SHA1这样的简单哈希,我想说一个单四核服务器,假设编程技术很好,可以处理每秒10,000个请求的粗略范围.它完全取决于webapp框架&使用的编程,因为HTTP连接处理开销将主导SHA1计算速度.如果我们在prefork模式下使用Apache与fx PHP,那么这些数字将更加可爱,每台服务器每秒可能需要2,000个请求.
let’s say you have a requirement for a system that cannot use tar-pitting or temporary account disabling
然后改变要求 – 这已经超出修复范围.
the number of actual login attempts per second on a web-based system is very useful.
同样,你应该有警报,在它变得庞大之前很久就会通知你一个暴力攻击.
