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
You need separate monitors / alerts on:
A spike on failed logins is a clue for brute force and credential stuffing
logins for non existent users,
A spike in logins for non existent users is a clue for credential stuffing – these are the mismatched emails / usernames you don’t have on your system being stuffed in
have a long look at both failed login monitoring alert sensitivities, assume the worst on any prolonged tickle.
A spike in successful logins only could be a clue someone’s stolen your user credentials from your DB (though why they’d then swarm your login page is a mystery)
Accounts locked due to repeated failures
again indicative clue to brute forcing
Any other key metrics you capture around login or account traversal (changing card details, changing user email addresses) should also be emitted and measured for unusual activity
these are post breach, so not ideal – but still very worthwhile in case you miss something subtle initially
The detection thresholds on these login attempts alerts should ideally be sophisticated and use correlations, anomaly detection and machine learning – it’s the only way to really spot the low and slow subtle attacks
When under Attack
Turn on Captcha
Look for patterns in the attack, are there clues to specific hack tool – perhaps repeating user agent strings, odd protocols like TLS1 or timings that you may be able to profile.
you can set some irules for repeated 401/3s from a single IP to ban on the IP for 10 minutes for example.
Dump suspicious IPs from threat intelligence reports or with high volumes altogether
Or rules to filter on unusual user agents / matching TLS profiles (though this may collateral damage or shedding some real users)
Block IPs outside your customer geography location if possible, any other way of shedding suspicious traffic?
Check threat intelligence sources looking up the dodgy IPs you see for more info
Slow down logins, irritating for users, but throttles the attack
Are accounts being compromised, if so is there a pattern – can you get ahead if so?
Try to catch the traffic as lose to the perimeter of your network
Check this isn’t just a feint for something worse. Check your other alerts for signs of intrusion to backend systems while they’ve kept you busy chasing this login tidal wave.
Call the Police
Call the FBI / GCHQ / Cyber authority in your geography
They can perhaps perform ‘Upstream Disruption’:
Shutting down sites the tools being used are deployed on
Identifying and Arresting individuals performing the attacks
Throttling traffic at ISPs or even further upstream
Have an incident plan ready – it’s a fair bit of planning but pays off in a crisis.
Comms is key:
Internal folk (tell them don’t say too much)
Different customer classes (tailor)
Regulatory bodies in your industry
be careful of any precedent for refunds / goodwill
Consider getting hack insurance in advance
Police – report as a crime
Gchq / FBI
involve your legal team and have them run their eye over comms.
Call or drop Anna a line if you need advice about the services we offer or you might need…suggestions/feedback always welcome…no matter how wacky or off the wall!
Francesca mostly focuses on client happiness these days so ping her if you are happy/unhappy with what we’re doing/could be doing/should be doing…she loves sorting things out!
Ping Josh with any comments/questions/issues with gro.team’s web or mobile sites..Josh loves nothing more than talking about cool UX stuff he should look at…