I'm trying to do some very simple request throttling on my ASP.NET web project. Currently I'm not interested in globally throttling requests against DOS attacks, but would like to artificially delay the reponse to all login attempts, just to make dictionary attacks a bit harder to do (more or less like Jeff Atwood outlined here).
How would you implement it? The näive way of doing it would be - I suppose - to simply call
Thread.Sleep();
somewhere during the request. Suggestions? :)
Kevin makes a good point about not wanting to tie up your request thread. One answer would be to make the login an asychronous request. The asychronous process would just be to wait for the amount of time you choose (500ms?). Then you wouldn't block the request thread.
I would place the delay on the server validation portion where it won't attempt to validate (come back automatically as false have a message saying the user has to wait so many seconds before making another attempt). another answer until so many seconds have passed. Doing the thread.sleep will prevent one browser from making another attempt, but it won't stop a distributed attack where someone has multiple programs trying to login as the user simultaneously.
Another possibility is that the time between attempts varies by how many attempts are made to login. So the second attempt they have a one second wait, the third is maybe 2, the third is 4 and so on. That way you don't have a legitimate user having to wait 15 seconds between login attempts because they mistyped their password incorrectly the first time.
I don't think what you are asking for is quite an efficient way in a web enviornment. Login screens' purpose is to provide an easy way for 'users' to gain access to your services and should be easy and fast to use. So you should not make a user wait considering 99% of the them will not be bad-minded.
Sleep.Trhead also has the potential to place a huge load on your server should there be a lot of concurrent users trying to log in. Potential options would be:
of course these are not all the options but still I am sure more people will have more ideas...
I know it's not what you're asking, but you could implement an account lockout instead. That way, you give them their guesses and then can make them wait any amount of time you want before they can start guessing again. :)
I don't think this will help you thwart DOS attacks. If you sleep the request thread, you are still allowing the request to occupy your thread pool and still allow the attacker to bring your web service to its knees.
Your best bet may be to lock out requests after a specified number of failed attempts based on the attempted login name, source IP, etc, to try and target the source of the attack without detriment to your valid users.
I got the same idea as you on how to improve the security of a login screen (and password reset screens). I'm going to implement this for my project and I'll share my story with you.
Requirements
My requirements are in following points:
Plan
So we shall have a list of failed attempts and their time stamp. Every time we have a login attempt, we'll check this list and the more there are failed attempts, the longer it will take to login. Each time we'll prune old entries by their time stamp. Beyond a certain threshold, no logins will be allowed and all login requests will be failed immediately (attack emergency shut-down).
We do not stop with the automatic protection. A notification should be sent to admins in case of the emergency shut-down so that the incident can be investigated and reparation measures can be taken. Our logs should hold a firm record of the failed attempts including the time, user name and source IP address for investigation.
The plan is to implement this as a statically declared queue, where failed attempts enqueue and old entries dequeue. the length of the queue is our indicator of severity. When I've got the code ready, I'll update the answer. I might include Keltex's suggestion too - releasing the response quickly and completing the login with another request.
Update: There is two things missing:
Let's see if we can get through that eventually...
What's done
ASP.NET page
ASP.NET UI Page should have minimum hassle, then we get an instance of a Gate like this:
And after login (or password reset) attempt, call:
ASP.NET handling code
The LoginGate is implemented inside the AppCode of the ASP.NET project so it has access to all the front-end goodies. It implements the interface IGate which is used by the backend SecurityDelayManager instance. The Action method needs to be completed with wait redirection.
Backend somewhat thread-safe management
So this class (in my core lib) will handle the multi-threaded counting of attempts:
Tests
And I've made a test fixture for that: