This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Talk:Credential Stuffing Prevention Cheat Sheet"
Douglasheld (talk | contribs) (formatting) |
Douglasheld (talk | contribs) (add bad passwords check) |
||
| Line 7: | Line 7: | ||
* this includes making no distinction to the response when an existing account is locked out | * this includes making no distinction to the response when an existing account is locked out | ||
| − | 2. | + | 2. Reject commonly used or already breached passwords. If your users propose these, force them to use a better password. See https://haveibeenpwned.com/Passwords |
| − | 3. | + | 3. Consider lockout mechanisms additionally from an identified source, and also to an identified target. So for instance, lock out an account after X failed login attempts; but also perhaps lock or throttle logins on an entire tenancy or an entire region if the failed logins per time break above a threshold value. Under a credential stuffing attack, if you were to return 50% of login requests with 503 Unavailable, then a legitimate user has a 50% chance of getting in on the first try, while the attacker's goal will be stretched to twice of its former effort estimate. |
| − | 4. If your application is sensitive to performance, consider segregating your operational environment between login activities and logged in activities. This way, users already logged in successfully can continue to use the application at full performance, while the segregated area dedicated to logins may have to start rejecting requests when it is under attack. Also, segregated resources allow you to more easily incorporate performance-hitting security features like harder working password hashes, or delayed responses by sleeping threads a while to confound various timing attacks. | + | 4. Captchas can be a very useful throttling technique. |
| + | |||
| + | 5. If your application is sensitive to performance, consider segregating your operational environment between login activities and logged in activities. This way, users already logged in successfully can continue to use the application at full performance, while the segregated area dedicated to logins may have to start rejecting requests when it is under attack. Also, segregated resources allow you to more easily incorporate performance-hitting security features like harder working password hashes, or delayed responses by sleeping threads a while to confound various timing attacks. | ||
[[User:Douglasheld|Douglasheld]] ([[User talk:Douglasheld|talk]]) 08:40, 8 July 2018 (CDT) | [[User:Douglasheld|Douglasheld]] ([[User talk:Douglasheld|talk]]) 08:40, 8 July 2018 (CDT) | ||
Latest revision as of 13:45, 8 July 2018
The prerequisites to Credential Stuffing are to have a likely list of usernames or a particular username you would like to attack. Also, a list of most common passwords or an algorithm to try random passwords without repeating a password for a particular username.
Some mitigations that aren't mentioned here are:
1. Try to reduce the ease of obtaining a list of authorized users
- Make no different response from a login attempt to an existing vs. nonexistent account
- this includes making no distinction to the response when an existing account is locked out
2. Reject commonly used or already breached passwords. If your users propose these, force them to use a better password. See https://haveibeenpwned.com/Passwords
3. Consider lockout mechanisms additionally from an identified source, and also to an identified target. So for instance, lock out an account after X failed login attempts; but also perhaps lock or throttle logins on an entire tenancy or an entire region if the failed logins per time break above a threshold value. Under a credential stuffing attack, if you were to return 50% of login requests with 503 Unavailable, then a legitimate user has a 50% chance of getting in on the first try, while the attacker's goal will be stretched to twice of its former effort estimate.
4. Captchas can be a very useful throttling technique.
5. If your application is sensitive to performance, consider segregating your operational environment between login activities and logged in activities. This way, users already logged in successfully can continue to use the application at full performance, while the segregated area dedicated to logins may have to start rejecting requests when it is under attack. Also, segregated resources allow you to more easily incorporate performance-hitting security features like harder working password hashes, or delayed responses by sleeping threads a while to confound various timing attacks.
Douglasheld (talk) 08:40, 8 July 2018 (CDT)
