Defending against Credential Stuffing Attacks
Credential stuffing is an attack where attacker writes a script to automatically make username/password login attempts on a target service, with leaked passwords from other websites. If your service uses username/password for login, it may be affected.
Measures against Credential Stuffing could be categorized into:
Remove usage of passwords (Best)
Add friction to login in addition to passwords (Second best)
Slow down automated login attempts (Easy, but not so useful)
Here is a list of countermeasures in the order of preference.
Replace password login with password-less login.
Difficulty: π§π§π§ (client, server-side changes)
Effectiveness: πππππ best solution, completely solves the problem
Comment: If password is no longer accepted, credential stuffing attack no longer works. Password-less login is relatively easy to implement.
Considerations:
Password-less login requires client changes. Mobile client changes will require a force client upgrade.
Email/Social login is preferred. Phone SMS login causes other issue because phone number could be rotated.
Remember to remove password login API endpoint.
Implement multi-factor authentication
Difficulty: π§π§π§π§π§ (client, server-side changes)
Effectiveness: ππππ greatly reduced risks
Comment: 2FA denies attacker the access to sensitive info with password only.
Considerations:
2FA adds friction to user experience. Consider using adaptive MFA (only prompt if new device or location) to reduce friction if possible. Or only require 2FA for sensitive activities.
2FA implementation may also require client-side change. 2FA adds a lot of logic into the login process, itβs difficult to get right (handle the situation where your second factor is lost, for example).
Deny usage of leaked passwords
Difficulty: π§π§ (server-side changes only)
Effectiveness: πππ the solution is only as good as your password list
Comment: Collect a list of leaked passwords and reject passwords on the list. This could use the help of a bloom filter.
Implement CAPTCHA to slow down automation
Difficulty: π§π§π§π§ (client, server-side changes)
Effectiveness: πππ denies automation but manual attack is still possible
Comment: CAPTCHA makes automated validation of passwords more difficult.
Considerations:
CAPTCHA implementation requires client-side changes.
CAPTCHA only makes the automated attacks manual or difficult to automate.
Rate limit, IP-based blocking or risk-score based blocking of attempts.
Difficulty: π§ (server-side changes only)
Effectiveness: π easy to bypass
Comment: Setting up rule-based blocking or rate-limit is simple. However itβs also not difficult to by-pass with the use of proxies. Determined attacker can find ways around within days. Itβs a cat-and-mouse game.
Strong password policies
Difficulty: π§ (server-side changes only)
Effectiveness: π barely helps
Comment: Strong passwords also get leaked on other websites.
Honorable mentions of detective measures:
Notifying user with new logins.
System monitoring of abnormal login attempts.
Conclusion
A number of common measures against Credential Stuffing attacks are discussed here. The best solution is to completely remove the usage of passwords. If removing password isnβt possible, a combination of measures could be implemented. Server-side only measures are easy to implement but usually less effective. Measures involving client-side changes, however, alter the user flow and takes a longer time to implement.