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.

cicd

Defending against Credential Stuffing Attacks