but most web applications would not be capable of handling more than 100 sign-in requests per second.
What this means is: The author of that article makes an unsubstantiated (but not entirely unreasonable) claim that sending more than 100 signins per second would be an effective denial of service attack against "most" web applications.
For each sign in, a typical webapp would have to hash the password, and compare it against the hashed representation in the database. If the webapp uses a good hashing function, this does indeed use a fair amount of CPU. So the claim is perhaps not entirely unreasonable, but in my experience most webapps just use a simple hash like MD5, SHA1 or SHA256 which isn't CPU intensive.
The big error in that article comes here:
Note: The examples below are based on 100 password request per second.
In the next paragraphs the author makes suggestions for password strength, based on a maximum attack rate of 100 attempts per second. That may be a reasonable number for an online attack, where the attacker connects to the live web application.
But for a on offline attack, where the attacker has first downloaded the entire database via fx an SQL injection attack, that's entirely wrong. For example, here is a NVIDIA CUDA implementation for SHA1, which can do 47 million hashes per second on a small server cluster.
web applications only need to be able to protect against 100 attempts per second?
Sorry, but no, you're misunderstanding this part. Now you're looking at it from the perspective of webapp owner trying to protect against an online brute-force password guessing attack. You should take action long before it comes to this.
- If individual accounts have a certain number of failed log in attempts (3,5,10,25 can all be reasonable numbers) then the account should be temporarily disabled. (Or better yet, don't disable the account but slow down the login attempts, a.k.a tarpitting / rate limiting.)
- If you're getting hundreds of failed login attempts per second system-wide, then your logging / monitoring framework (Nagios etc) should be screaming alerts at you, so that you aware of the attack.
Lastly, you might want to read the FAQ that goes with the article, it makes the authors meaning more clear. He's talking about how end users can generate reasonably secure and still easy to remember passwords -- not about the server-side handling of passwords.
Update, after the question edit:
Based on the current average performance of most web servers, what is the maximum number of login attempts possible during a brute force attack?
For a simple hash like SHA1, I would say a single quad core server, assuming good programming techniques, could handle in the very rough ballpark of 10,000 requests per second. It will totally depend on the webapp framework & programming used, because the HTTP connection handling overhead will dominate over the SHA1 calculation speed. If we're using Apache in Prefork mode with fx PHP, then the numbers would be much lover, perhaps 2,000 request per second per server.
let's say you have a requirement for a system that cannot use tar-pitting or temporary account disabling
Then change the requirements -- that's broken beyond repair.
the number of actual login attempts per second on a web-based system is very useful.
Again, you should have alerting which notifies you of a brute-force attack long before it gets this massive.