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.

1. 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.

2. 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).

3. 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.

4. 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.

5. 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.

6. 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.

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.