2.5 KiB
Login Throttling
CAPTCHA Throttling
We have login captcha throttling in place for the following:
Tracked behavior | CAPTCHA threshold | Time Interval |
---|---|---|
Repeated unsuccessful attempts with the same username | 3 attempts | 10 minutes |
Repeated attempts from the same IP address | 3 attempts | 12 hours |
Repeated attempts using the same Sift ID | 3 attempts | 30 minutes |
Invalid or missing CSRF token | Immediate | N/A |
Missing customer cookie | Immediate | N/A |
When a user meets one of the thresholds above, they will be presented with a CAPTCHA challenge. This does not necessarily mean a puzzle will have to be solved, only that the CAPTCHA script will attempt to determine if the user is a bot. Even if the user has correctly entered their credentials on the subsequent attempt, the CAPTCHA challenge will still occur.
All of the above thresholds are checked concurrently for each login attempt.
When a throttled user logs in successfully, the following occurs, the username threshold is reset. No other thresholds are cleared. This means that even after a user is able to successfully log in to an account, it is still possible for them to be throttled after failing to log in again because they are now being throttled by IP address.
Sift ID Blocking
During previous login attacks, we've documented a set of Sift IDs that have been used repeatedly during those attempts. Those IDs are blocked with CAPTCHA immediately, with a 20% chance that we will present them a faked successful response. This is done to throw off attackers using these IDs.
Code
All the captcha / throttling logic that’s currently in place lives in
aweber_app/controllers/account_controller.php, mainly in the loginAjax
and
isThrottled
methods. The repeated actions are tracked using
php5-vendors/vendors/throttler.php, which uses counters in Redis with a TTL
attached.
Graphs
Login attempts and throttling are graphed in Grafana on the Account Logins dashboard.