Yes, the 403 is delivered.
Visitors to the LogIn page or form do not always attempt to log in, though a visit to the LogIn page and an attempt to log in look the same in terms of page accesses. You’ll see “Login” followed by “Login”, with only the second one being the log in attempt. The script only takes note of actual failed log in attempts, but doesn’t count anything against calling up the LogIn box.
So, I don’t know how the Locker works but I think I see an issue.
I have a few bots that are trying a brute force attack and they are doing it at an extremely slow speed; like 1 try every 30 minutes. They will never hit the threshold I have set (something like 6 failed attempts in 20 minutes) but they will have 50 failed attempts in a row each day. My thought would be to have the locker use [x] attempts in a row then it’s locked out for [n] minutes/hours.
I know my current solution is to blacklist the IP for a few days/weeks but that is not a very elegant solution.
I can change login_limit and login_lock_duration from TINYINTs to SMALLINTs, thereby giving you a larger window for login fail checks.
The downside to that would be that a longer login_lock_duration would apply to someone honestly mis-typing his password x times.
The same issue would apply to someone who legitimately forgets their password and keeps trying it over and over.
6 of one half a dozen of the other I guess.
I’ve made the changes, but have no time until Friday to push an update.
One idea… if the “block IP for X minutes” value is set to 0, use the visitor’s history of failed logins to determine a blocking length. That way, if a visitor commits five login fails in five minutes, that IP is blocked for the next ten minutes, while another visitor who commits five login fails over 24 hours is blocked for 48 hours. Maybe hard code a minimum block, like fifteen minutes, with a slide toward 1:1 as the time approaches 24 hours.
Still trying to figure out one little thing. Shooting for Saturday, now.
