Defence Against The Dark Arts
Credential Stuffing attacks are where an existing list of usernames / email addresses and cracked passwords are replayed against your site by an attacker to perform Account Take Overs (ATOs).
The list of usernames / email addresses and their passwords are available on the dark web, and often originate from previous Database breaches like linked-in where the old ciphers used to encrypt passwords were weak and so have been cracked resulting in full login details for list of millions of users being available for replay.
Because so many users reuse passwords – replaying this list against your site will result in some valid logins for the attackers – and the they exfiltrate any personally identifiable information (PII) from the users account to then potentially sell.
PII are adollar or two depending on completeness – but if they can harvest 1000s or millions of PII entries by accessing that many accounts on your site – it’s lucrative business.
Various tools such as sentry.mba exist for performing these types of attack – and if the infiltration is ‘low and slow’ it’s very hard to detect a few failed logins per second amongst all the noise
Prevention / Preparation
Keep max login retry limits low (though in credential stuffing they have a username/password combo already this is minimal protection).
Make sure you rate limit based on sessionIds add a Captcha and reverse-Captcha by default on login, you should ‘feature toggle’ Captchas so it doesn’t have to be on all the time annoying your users.
If you want to get sophisticated you can make this risk based – so the Captcha only springs up when some aspect of the user is suspicious.(Google’s ‘recaptcha’ is pretty clever and non intrusive these days and does risk profiling too).
You still need a reverse capcha too though as this can be left on all the time as it’s invisible to users – there may be circumstances where product folk want to lift the ordinary user Captcha
ensure you’re returning 401 and 403 HTTP codes appropriately in your login validation code (this will facilitate efficient firewall rules).
if attacked you could set some irules for repeat 401/3 from a single IP be a ban on the Ip for 10 minutes for example, this not so easy if you just 302 to /failedlogin.html as you’ll have lots of other ligitimate 302s
Make sure you consider you APIs too – an API gateway of some sort should offer throttling mechanisms
Consider something like Cloudflare, Ravelin or their competitors – they do lots of profiling and filtering of supicious IPs and tools, or ATO plugins and may solve your problem invisibly upstream
Make sure you’ve built the capabilities for Password Reset and Account Suspension for corralling any compromised accounts.
Implement user device profiling, where each new device a user logs in from is recorded and exceptions flagged to users for validation – numerous libraries exist for this
Ensure you close the loop in verifying users email addresses and if possible phone numbers too.
Implment 2FA (2 factor authentication) or MFA ( Multi Factor Authentication) – the gold standard of login verification where users have some kind of key generator with them 9Authy / Google Authenticator Yubikey).
Though this may not be applicable for high volume sites with non technical users, offering it gives you options for expert users.
Do a red team simulation for credential stuffing to see if it gets spotted by your team.
During registration, consider a spot check on new credentials to haveibeenpwned.com or similar — and potentially warn them about strong unique passwords if their username/email is known (careful messaging required!)
See also OWASP’s guide on this at https://www.owasp.org/index.php/Credential_stuffing