Timeline for Circumventing disadvantage of IP-based account lockout
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 20, 2015 at 21:05 | history | edited | AJAr | CC BY-SA 3.0 |
added 6 characters in body
|
| Feb 20, 2015 at 21:04 | comment | added | AJAr | If a primary concern is DOS, then it's not uncommon for sites to require a CAPTCHA following even the first failed attempt, then for any attacks following that restriction you can say with reasonable certainty that it is a human trying to breach a user's account. With that, disallowing login attempts into that one account from IP address Y would also help to mitigate attacks while inconveniencing neither the victim on their healthy IP address nor other users from the unhealthy shared IP address Y. | |
| Feb 20, 2015 at 20:50 | comment | added | AJAr | Account-bound CAPTCHA threshold which could work alongside an IP-bound CAPTCHA limitation if it ever became an issue, but I wouldn't recommend that for the reasons you talked about in the original question (inconveniencing users of a shared IP). If you wanted to do a full-force account lock at any point, you might do that at 2N attempts if N is the account-bound CAPTCHA threshold. You could use historical login IP geolocation as a consideration as well, even if it's just to the extent of informing the true account-holder of malicious origins. | |
| Feb 20, 2015 at 20:39 | comment | added | AlexMA | Are you suggesting account-specific lockout, or account-specific CAPTCHA if we're removing the IP address from the equation? | |
| Feb 20, 2015 at 20:38 | history | edited | AJAr | CC BY-SA 3.0 |
added 374 characters in body
|
| Feb 20, 2015 at 20:32 | history | answered | AJAr | CC BY-SA 3.0 |