Merge pull request OWASP#90 from mackowski/credential-stuffing

Credential stuffing

cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.md

@@ -10,13 +10,19 @@ It should be noted that defense mechanisms are intended to be used in a layered
 
 In many cases, brute force protections will overlap with credential stuffing defenses.
 
+Keep in mind that application can have different security levels for different users/roles or actions. For example for casual customers multi-factor authentication may be optional but for admins or some other special roles it should be enforced.
+
 ## Defense Option 1: Multi-Factor Authentication
 
 True multi-factor authentication is the best defense against Credential Stuffing attacks, but can have significant deployment and usability impacts, and so is frequently not a feasible option. If this defense is not feasible for your application, consider adopting as many of these other defenses as you can.
 
-## Defense Option 2: Multi-Step Login Process
+In order to balance security and usability, multi-factor authentication can be combined with other techniques to ask for 2nd factor only in special situations. For example, it can be combined with [device fingerprinting](cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.md#defense-option-4-device-fingerprinting), in that scenario, the application can ask for a 2nd factor only when the application is accessed by an unknown, new browser. Similary, cookies can also be used for remembering known browsers or the application can ask about another factor based on the login success ratio, IP address (like users from different network than company one like remote workers) etc.
 
-*Most of the automated account validation we've seen is using single step validation and checking for a success conditions. By forcing the client to render the response and include that in the next request (and including [Synchronizer (CSRF) Tokens](Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md)), we are just eliminating the basic attempts. It's not comprehensive.*
+## Defence Option 2: Use a CAPTCHA
+
+Similar to Multi-Factor Authentication this defence can be combined with other techniques to ask user to solve CAPTCHA only in special situations. 
+
+Lots of CAPTCHA examples can be reviewed [here](https://www.whoishostingthis.com/resources/captcha/)
 
 ## Defense Option 3: IP blacklists
 
@@ -36,10 +42,41 @@ How you deal with mismatches is also a major consideration. If you are performin
 
 Using simple fingerprinting, with maybe 2 or 3 variables would require that less stringent actions be taken, due to it's higher likelihood of a false positive. In this case, maybe the source IP is blocked if it attempts more than 3 user IDs.
 
+Example library that can be used is [fingerprintjs2](https://github.com/Valve/fingerprintjs2)
+
 ## Defense Option 5: Disallow Email Addresses as User IDs
 
 In many cases, credential reuse is an issue because user IDs are the same on multiple sites. In most cases, they are the email address of the user, for usability. This is an obvious problem when considering Credential Stuffing. One possible approach is to avoid use of email addresses as userids. Not using email addresses as userids also helps prevent spearfishing attacks against such users, because the email associated with the user account is far less obvious.
 
+# Secondary Defenses
+
+These techniques are, in most cases, only slowing the attacker down. If the credential stuffing is a serious threat to you, they can buy you some time to defend against ongoing attacks. They can be also useful, against opportunistic attackers, who use standard tools and probably will choose easier targets to attack.
+
+## Multi-Step Login Process
+
+*Most of the automated account validation we've seen is using single step validation and checking for a success conditions. By forcing the client to render the response and include that in the next request (and including [Synchronizer (CSRF) Tokens](Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md)), we are just eliminating the basic attempts. It's not comprehensive.*
+
+## Require JavaScript and/or block headless browsers
+
+Requiring JavaScript will increase cost of attack because attacker have to run real browser.
+Blocking headless browsers is another step after requiring javascript to block browsers similar to PhantomJS or Headless Chrome. To detect such browsers application should check JavaScript properties that are used in these browsers like:
+`navigator.webdriver`, `window._phantom`, `window.callPhantom` and user-agents `PhantomJS`, `HeadlessChrome`.
+
+## Pwned Passwords
+
+Application can check whether passwords used by users were previously or recently exposed in data breaches. After check application can either notify user about it or force changing password to new one. Trustworthy, big and updated data source for such password is Troy Hunt’s service - [Pwned Passwords](https://haveibeenpwned.com/Passwords). You can host it yourself or use [API](https://haveibeenpwned.com/API/v2#PwnedPasswords). 
+In order to protect the value of the source password being searched for, Pwned Passwords implements a [k-Anonymity model](https://en.wikipedia.org/wiki/K-anonymity) that allows a password to be searched for by partial hash. This allows the first 5 characters of a SHA-1 password hash to be passed to the API.
+
+Remember that you should have access to passwords only just after user log-in or register new account (after that passwords will be stored in [hashed form](cheatsheets/Password_Storage_Cheat_Sheet.md#leverage-an-adaptive-one-way-function)). This is the only one place, where you can check if password was leaked. Make sure that you do not log or store plaintext password during this operation.
+
+## Notify users about unusual security events 
+
+Many applications sends notification to their users about unusual security events like: password change, e-mail change, login from new browser, high number of unsuccessful logins etc. This notifications are useful because it allows users to verify and take actions themselves e.g. change password, invalidate sessions or contact your support if the action was really malicious. It will help you spot the real issue and allow you to defend user.
+
+There is also a risk associated with such notifications, if your customers will receive a lot of such messages with false positives or if they don't understand the message it may cause more harm than good.
+
+You may go further and create full webpage with recent security events.
+
 # References
 
 - [OWASP Credential Stuffing Article](https://www.owasp.org/index.php/Credential_stuffing)
@@ -48,4 +85,4 @@ In many cases, credential reuse is an issue because user IDs are the same on mul
 
 # Authors and Primary Editors
 
-Brad Causey
+Brad Causey