2

This insightful article proposes that passwords don't need to be very secure: http://www.baekdal.com/tips/password-security-usability?

There is one specific line in here that I find troubling:

The actual number varies, but most web applications would not be capable of handling more than 100 sign-in requests per second.

Is it true that most web applications only need to be able to protect against 100 attempts per second? Seems like a very low number when you deal with distributed systems that can be attacked by multiple intruders.

EDIT More clarification on my question: Based on the current average performance of most web servers, what is the maximum number of login attempts possible during a brute force attack? I'm not asking about offline password attacks where someone can really crank out login attempts.

Put into perspective, let's say you have a requirement for a system that cannot use tar-pitting or temporary account disabling (in order to prevent hackers from DoS through login attempts), the number of actual login attempts per second on a web-based system is very useful.

3
  • 2
    If this concerns you, you should look into an IDS system which is capable of detecting brute-force attacks. Apr 16, 2011 at 0:00
  • And at some point, anyone with a publicly available website should be concerned. Apr 16, 2011 at 3:35
  • id: John password: John --- happens more than you'd like to think
    – Paul
    Apr 17, 2011 at 4:58

4 Answers 4

3

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.

  1. 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.)
  2. 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.

1
  • While I don't agree with your "change the requirements" comment, showing a theoretical maximum of 2k is very useful so I am selecting this answer.
    – pokstad
    Apr 18, 2011 at 16:19
1

How are we to answer something about "most" web applications? Most are probably on company intranets, for a start, but also you are probably out of "most" by the time you get to web apps running on 2+ servers.

Anyway, I don't think it says you will only get 100 requests per second so that's all you need to defend against, which is how your question sounds, but rather that you can probably only handle 100 requests per second (which is 60,000/minute) so that level makes a good tradeoff.

If your app can handle 1000x logins per second, maybe rethink things.

The article doesn't mention tar-pitting, which is the practice of slowing down login replies so brute forcing becomes impossible - you may have seen it yourself where you try to login 5 times and after that each time you type a password it sits there churning for ages before telling you it failed, and after 10 tries the delay gets bigger. Keep trying and it keeps slowing down, but leave and come back in twenty minutes and it's fast again.

Doing that can make brute forcing almost impossible.

1
  • +1 For tar-pitting, didn't know the name for that.
    – pokstad
    Apr 16, 2011 at 17:52
0

The author of that article is making a huge assumption about the number of requests that "normal" web applications can handle. If your site is on a dedicated server with well-written code, it may well be able to handle 1,000 requests per second without breaking a sweat. An older server without any sort of optimization may only be able to handle 10 requests per second before it starts to grind to a halt. The author had to pick a number to base his calculations on and 100 seems like a reasonable place to start.

If you're trying to defend against brute-force or dictionary attacks, you can use a variety of techniques such as tar-pitting, as TessellatingHeckler mentioned, or putting temporary locks on the account as suggested by the article. I've even seen systems that will simply ignore requests from any IP that it sees send requests above a certain rate.

As to the original question, the attacker will want to be able to try as many passwords as possible while NOT bringing the server down, so it's not that you need to be able to "defend against" a particular number of requests per second as the attacker will rate-limit their own tools if they see it causing slowdowns on the server because it is in their best interests not to draw attention to themselves. Just design your application to be able to handle your expected normal load plus some reasonable margin for growth and the occasional spike in traffic.

If you're worried about generic DDoS attacks, that is a different matter entirely and has nothing to do with requests per second for password attempts.

3
  • 1
    Putting temporary locks on is a bad idea, as it allows any user to lock out any other users at will - and keep them locked out for as long as they like. At least do it on a per-client-IP basis. Apr 18, 2011 at 14:35
  • Yea, temporary locks are not a good idea when a hacker can just lock a legitimate user out.
    – pokstad
    Apr 18, 2011 at 16:16
  • I agree it can be annoying, but if the lock is temporary (say, 20 minutes) then depending on how often users are authenticating it may or may not become a problem. It can also be a great way to identify user accounts that are being targeted and monitor them more closely if an account is being regularly locked out. Comparing the origin IP addresses for good vs. bad attempts can also be a good way to dynamically lock out ranges of IPs if one subnet is continually locking the account. Apr 18, 2011 at 21:07
0

You can implement easy jail for brute-forcers. Say after 3 failed logins you block logins from that ip for 1(or more) minute(a), but just keep sending to client user/password missmatch

Another way is to separete user and admin logins. say, you are making some main form for user logins and put near it fake button for admin login witch always will say "Incorect password". and make some hidden web-page for real admin login:D

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .