Talk:Credential Stuffing Prevention Cheat Sheet - Revision history

Douglasheld: add bad passwords check

2018-07-08T13:45:02Z

add bad passwords check

Douglasheld: formatting

2018-07-08T13:42:13Z

formatting

Douglasheld: Some further ideas not expressed in the article

2018-07-08T13:40:53Z

Some further ideas not expressed in the article

New page

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. 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.
3. Captchas can be a very useful throttling technique.
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.
[[User:Douglasheld|Douglasheld]] ([[User talk:Douglasheld|talk]]) 08:40, 8 July 2018 (CDT)

@@ Line 7: / Line 7: @@
 * this includes making no distinction to the response when an existing account is locked out
-. 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.
+. Reject commonly used or already breached passwords. If your users propose these, force them to use a better password. See https://haveibeenpwned.com/Passwords
-.  Captchas can be a very useful throttling technique.
+. 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.
-. 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.
+.  Captchas can be a very useful throttling technique.
 [[User:Douglasheld|Douglasheld]] ([[User talk:Douglasheld|talk]]) 08:40, 8 July 2018 (CDT)

@@ Line 2: / Line 2: @@
 Some mitigations that aren't mentioned here are:
 . 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
+* 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
+* this includes making no distinction to the response when an existing account is locked out
 . 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.
 .  Captchas can be a very useful throttling technique.
 . 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)