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

Credential Stuffing Prevention Cheat Sheet

From OWASP
Revision as of 16:29, 20 September 2016 by Bradcausey (talk | contribs)

Jump to: navigation, search

DRAFT CHEAT SHEET - WORK IN PROGRESS

This document is a work in progress.

Introduction

Credential stuffing is the automated injection of breached username/password pairs in order to fraudulently gain access to user accounts. This is a subset of the brute force attack category: large numbers of spilled credentials are automatically entered into websites until they are potentially matched to an existing account, which the attacker can then hijack for their own purposes.

[https://www.owasp.org/index.php/Credential_stuffing]

Authors and Primary Editors

TODO

Primary Defenses

It should be noted that defense mechanisms are intended to be used in a layered approach. In most cases, a single defense option would be inadequate to stop most Credential Stuffing attacks.

In many cases, brute force protections will overlap with credential stuffing defenses.

Defense Option 1: Multi-Factor Authentication

TODO

Defense Option 2: 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) we are just eliminating the basic attempts. It's not comprehensive.

Defense Option 3: IP blacklists

Because the attacker requests will likely originate from a few (or one) IP, addresses attempting to log into multiple accounts can be blocked or sandboxed.

Further, login monitoring with IP tracking could be used to eliminate (most) false positives. Use the last several IPs that the user's account logged in from and compare them to the suspected "bad" IP.

Making the IP bans temporary, say 15 minutes, would reduce the negative impact to the customer and business services (who would have to fix false positives) significantly.

Defense Option 3: Device Fingerprinting

By running some simple javascript device information collections, you can learn certain things about the device(s) used to log into each account. If a Windows(OS)/Engish(Language)/Chrome(Browser) device logged in the last 5 times, and we have a new geolocation source with Linux/FireFox/Spanish, then we can be pretty certain that the user is not the original one. (other options include timezones, last login times, user agents, java version, flash, etc)

The most simple implementation, while minimizing reduction in effectiveness, would be Operating System + Geo Location + Language.

Other Cheatsheets

OWASP Cheat Sheets Project Homepage