Timeline for Why do sites implement locking after three failed password attempts?
Current License: CC BY-SA 2.5
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 22, 2010 at 15:27 | comment | added | Bradley Kreider | I think AviD's point is that the session component could be automated in which case you are only defeating brute-forcing via browsers (ie: a person attempting brute force or ugly browser automation). The other issue is that the response delay is more likely to hit valid users, rather than discourage an automated brute-force attack. If 99% of users get it right in under 10 tries and you can't be brute forced in 10 tries, it's probably a good idea to set the limit to 10 (made up numbers for an example). | |
| Nov 22, 2010 at 14:02 | comment | added | Josh | In this particular case it was impossible to get to this point without having session enabled. But admitedly a better approach would have been to maintain the locking statistics in the database. For us we had a certain set of event ID's being logged, and monitored. If at any point a large number of attempts had come in for the same user... we would have known pretty quickly. | |
| Nov 22, 2010 at 10:53 | comment | added | AviD♦ | @Dan, you're right - but they might even come from the SAME endpoint, but without a browser. And, sessionless - each request is a new session. so "session was ended" is also pointless | |
| Nov 19, 2010 at 13:39 | comment | added | Dan McGrath | Brute force attempts quite possibly don't come from a single end point which makes the 'close browser' a moot point. | |
| Nov 19, 2010 at 13:37 | history | answered | Josh | CC BY-SA 2.5 |