I was just reading this post The definitive guide to form-based website authentication on Preventing Rapid-Fire Login Attempts.
Best practice #1: A short time delay that increases with the number of failed attempts, like:
1 failed attempt = no delay
2 failed attempts = 2 sec delay
3 failed attempts = 4 sec delay
4 failed attempts = 8 sec delay
5 failed attempts = 16 sec delay
etc.
DoS attacking this scheme would be very impractical, but on the other hand, potentially devastating, since the delay increases exponentially.
I am curious how I could implement something like this for my login system in PHP?
Store fail attempts in the database by IP. (Since you have a login system, I assume you know well how to do this.)
Obviously, sessions is a tempting method, but someone really dedicated can quite easily realize that they can simply delete their session cookie on failed attempts in order to circumvent the throttle entirely.
On attempt to log in, fetch how many recent (say, last 15 minutes) login attempts there were, and the time of the latest attempt.
You have three basic approaches: store session information, store cookie information or store IP information.
If you use session information the end user (attacker) could forcibly invoke new sessions, bypass your tactic, and then login again with no delay. Sessions are pretty simple to implement, simply store the last known login time of the user in a session variable, match it against the current time, and make sure the delay has been long enough.
If you use cookies, the attacker can simply reject the cookies, all in all, this really isn't something viable.
If you track IP addresses you'll need to store login attempts from an IP address somehow, preferably in a database. When a user attempts to log on, simply update your recorded list of IPs. You should purge this table at a reasonable interval, dumping IP addresses that haven't been active in some time. The pitfall (there's always a pitfall), is that some users may end up sharing an IP address, and in boundary conditions your delays may affect users inadvertantly. Since you're tracking failed logins, and only failed logins, this shouldn't cause too much pain.
cballuo provided an excellent answer. I just wanted to return the favor by providing an updated version that supports mysqli. I slightly changed up the table/field columns in the sqls and other small things but it should help anyone looking for the mysqli equivalent.
The login process needs reduce its speed for both successful and unsuccessful login. The login attempt itself should never be faster than about 1 second. If it is, brute force uses the delay to know that the attempt failed because success is shorter than failure. Then, more combinations can be evaluated per second.
The number of simultaneous login attempts per machine needs to be limited by the load balancer. Finally, you just need to track if the same user or password is re-used by more than one user/password login attempt. Humans cannot type faster than about 200 words per minite. So, successive or simultaneous login attempts faster than 200 words per minite are from a set of machines. These can thus be piped to a black list safely as it is not your customer. Black list times per host do not need to be greater than about 1 second. This will never inconvenience a human, but plays havoc with a brute force attempt whether in serial or parallel.
2 * 10^19 combinations at one combination per second, run in parallel on 4 billion separate IP addresses, will take 158 years to exhaust as a search space. To last one day per user against 4 billion attackers, you need a fully random alphanumeric password 9 places long at a minimum. Consider training users in pass phrases at least 13 places long, 1.7 * 10^20 combinations.
This delay, will motivate the attacker to steal your password hash file rather than brute force your site. Use approved, named, hashing techniques. Banning the entire population of Internet IP for one second, will limit the effect of parallel attacks without a dealy a human would appreciate. Finally, if your system allows more than 1000 failed logon attempts in one second without some response to ban systems, then your security plans have bigger problems to work on. Fix that automated response first of all.
The short answer is: Do not do this. You will not protect yourself from brute forcing, you could even make your situation worse.
None of the proposed solutions would work. If you use the IP as any parameter for throttling, the attacker will just span the attack across a huge number of IPs. If you use the session(cookie), the attacker will just drop any cookies. The sum of all you can think of is, that there is absolutely nothing a brute forcing attacker could not overcome.
There is one thing, though - you just rely on the username that tried to log in. So, not looking at all the other parameters you track how often a user tried to log in and throttle. But an attacker wants to harm you. If he recognizes this, he will just also brute force user names.
This will result in almost all of your users being throttled to your maximum value when they try to log in. Your website will be useless. Attacker: success.
You could delay the password check in general for around 200ms - the website user will almost not notice that. But a brute-forcer will. (Again he could span across IPs) However, nothing of all this will protect you from brute forcing or DDoS - as you can not programatically.
The only way to do this is using the infrastructure.
You should use bcrypt instead of MD5 or SHA-x to hash your passwords, this will make decrypting your passwords a LOT harder if someone steals your database (because I guess you are on a shared or managed host)
Sorry for disappointing you, but all the solutions here have a weakness and there is no way to overcome them inside the back-end logic.
or as suggested by Cyro:
It's a bit rough, but the basic components are there. If you refresh this page, each time you refresh the delay will get longer.
You could also keep the counts in a database, where you check the number of failed attempts by IP. By using it based on IP and keeping the data on your side, you prevent the user from being able to clear their cookies to stop the delay.
Basically, the beginning code would be: