Timeline for Brute force prevention: where and when?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 25, 2017 at 19:46 | comment | added | alex.forencich | You don't have to extend a successful login...the important point is to make all failed logins take the same amount of time regardless of the reason for failure such that it's not possible to determine bad username vs bad password vs locked account, etc. | |
| Nov 24, 2017 at 15:51 | history | edited | mr.spuratic | CC BY-SA 3.0 |
added 95 characters in body
|
| Nov 24, 2017 at 15:11 | history | edited | mr.spuratic | CC BY-SA 3.0 |
added 369 characters in body
|
| Nov 24, 2017 at 15:04 | comment | added | user | "use account lockout and source IP lockout" This can cause a denial of service against the user accounts involved. It's probably better to use a CAPTCHA or otherwise proof-of-work for the client when too many invalid logins have been attempted, either for a given account since the most recent successful login, or in general (e.g. from any particular IP address or network). | |
| Nov 24, 2017 at 13:40 | comment | added | My1 | "make it hard/impossible for an attacker to determine valid user names, invalid passwords or locked out accounts" this might be adding to security on the login but usually the registration is open to this as it is checked whether the name is available or not, and in the end it usually only annoys the user. in a closed community though, it can really help. | |
| Nov 24, 2017 at 12:34 | vote | accept | rew1nd | ||
| Nov 24, 2017 at 12:01 | history | edited | mr.spuratic | CC BY-SA 3.0 |
add CAPEC
|
| Nov 24, 2017 at 11:36 | history | answered | mr.spuratic | CC BY-SA 3.0 |