Credential Stuffing

Heya, Let’s talk about credential stuffing, a common form of attack against web applications. Credential stuffing targets usernames and passwords, which are still the lowest common denominator for online account access. You’ll learn about the architecture, security controls, and implementation choices necessary to protect user accounts from credential stuffing attacks. What Is Credential Stuffing Credential stuffing is an automated attack where malicious actors use stolen username-password pairs from one service to attempt unauthorized access to other services. Unlike brute force attacks that try many passwords against one account, credential stuffing exploits the widespread problem of password reuse across multiple platforms. Side note: please don’t reuse your passwords on any system you care about. Preventing credential stuffing matters for customer identity and access management (CIAM) systems because their entire reason for being is to prevent unauthorized access to the applications they are part of. This post focuses on defensive strategies for CIAM platforms hosting user accounts, not advice for individual users protecting their own credentials. But first, why should you care about this specific attack vector? Why Defending Against Credential Stuffing Matters Credential stuffing attacks are not theoretical concerns. They are happening right now, at scale, against services of all sizes. The attack vector is straightforward: attackers obtain databases of leaked credentials from breaches and systematically test these usernames and passwords against login endpoints across the internet. The economics favor the attacker. Credential databases are readily available, automation tools are sophisticated and cheap, and the success rate can be surprisingly high. When users reuse passwords, a single breach at one service becomes a skeleton key for other accounts across the web. For CIAM system operators, the consequences are severe. Successful account takeovers can lead to fraud, data theft, reputational damage, and regulatory penalties. Even unsuccessful attacks are problematic. They consume resources through increased load on authentication infrastructure. Support systems and employees also have to spend additional time handling locked accounts or identities that have been taken over. The fundamental challenge is that legitimate login attempts and credential stuffing attempts look very similar. A human typing their username and password and a bot submitting stolen credentials both send the same HTTP request. This makes naive defenses ineffective and therefore requires a layered approach. Core Defense Options Defending against credential stuffing requires multiple strategies. Unfortunately no single defense provides complete protection, but using a set of them can make attacks economically unattractive for attackers. Multi-Factor Authentication Multi-factor authentication (MFA) is the single most effective defense against credential stuffing. Even when the attempted credentials are valid, attackers cannot proceed without the second factor. Research suggests that MFA prevents the overwhelming majority of credential-based attacks. However, MFA is not a silver bullet. Why? Not every user will enable it. Requiring MFA can create friction at login that impacts conversion and user experience. MFA methods can be lost and removing them adds additional support load. The tradeoff is clear and one that you must weigh: security versus user convenience. You can help increase MFA adoption by using some of these tactics: Make non-password authentication methods like passkeys, one time codes, or social login the default path. Restrict access to sensitive operations for accounts without MFA. Offer multiple MFA options to accommodate different user preferences and capabilities. Implement step-up authentication; this requires additional MFA challenges and verification for high-risk actions rather than at every login. If you have multiple applications with different security needs, only require MFA on those that need more security. 100% adoption of MFA by customers for is unlikely, which means other defenses remain essential for protecting accounts that lack it. Breached Password Detection Checking passwords against databases of known compromised credentials provides an effective early warning system. Services like Have I Been Pwned (HIBP) maintain massive datasets of passwords exposed in breaches. When a user attempts to login with credentials matching these databases, the login attempt is suspicious. A CIAM system can take actions such as: limiting access locking an account forcing an immediate password change notifying the user via an email or other message Implementation of breached password detection by using a third party service like HIBP requires you to think about privacy. Informed users worry about sending their passwords to a third-party service. Privacy-preserving protocols address this concern by never transmitting the full password. You can instead send only a hash prefix. Another option is to keep the breached password corpus local to the CIAM system rather than use a third party service. Advanced breached password implementations can detect not just exact password matches but similar passwords. If an attacker obtains credentials for “password2024” and tries “password2025”, systems can flag the attempt as suspicious. Rate Limiting Rate limiting of login requests is a foundational defense, though credential stuffing attacks have evolved to bypass naive implementations. Simple per-IP rate limiting is ineffective against distributed botnets using thousands of different addresses. Effective request rate limiting in a CIAM system requires multiple approaches: per-account limits to prevent focused attacks on high-value accounts per-IP limits as a baseline defense global velocity checks to detect unusual patterns across the entire platform device fingerprinting to track behavior across IP addresses and allow for differential rate limiting The challenge is setting thresholds that best block attackers without overly impacting legitimate users. Too strict, and users who forget their password and try to login too many times too quickly get locked out. And frustrated. Too lenient, and attacks succeed. Walking this fine line requires regular tuning based on your application’s specific traffic patterns and responding to support requests. A good place to start is with generous limits. Then, tighten them as you gather data. Monitor false positives, where a legitimate login attempt is blocked, carefully. Users locked out of their accounts generate support costs and frustration. Device Cookies and Trusted Clients Device cookies create a distinction between known and unknown clients. When a user successfully authenticates from a device, that device receives a cryptographically signed cookie. Future login attempts from that device are more trustworthy. This enables differential rate limiting. Unknown devices attempting to authenticate can have much stricter rate limits. A botnet using thousands of unknown devices will quickly exhaust their allowed attempts across all those fresh clients, while legitimate users on their known devices have higher limits. Be careful when implementing this. The device cookie must contain at lest the username, a nonce, and an HMAC signature over the contents of the cookie. Depending on your needs, you might tie the cookie to a specific application and allow multiple on a device. You need to prevent attackers from forging cookies or tampering with existing ones to change the associated account information. Of course, some users regularly clear cookies or use multiple devices. Users who authenticate from a new device or cleared cookies will experience the stricter rate limiting until they successfully authenticate. However, since such users are unlikely to make tens of requests, let alone hundreds, they probably won’t trigger the rate limiting. Behavioral Analysis Moving beyond simple rules, behavioral analysis examines patterns in login attempts to distinguish humans from bots. A CIAM system can leverage JavaScript to capture typing patterns, mouse movements, time between field entries, then analyze them. Additionally, looking at the navigation flow of the request before the login page can provide valuable information. Sophisticated behavioral analysis can detect attacks that bypass other defenses. Bots behave differently from humans in subtle ways. In fact, humans differ from other humans as well; you can even perform keystroke biometric authentication. The downside is complexity and cost. Building behavioral analysis in-house requires substantial engineering resources. Third-party solutions like bot detection services are available but add a complex dependency as well as expense. Because of their nuance, use behavioral signals as inputs to a risk scoring system. An unusual typing pattern might not justify blocking a login attempt alone, but combined with other risk factors, can trigger an account lock or additional verification. CAPTCHAs and Challenges Completely Automated Public Turing tests to tell Computers and Humans Apart (CAPTCHAs) slow down automated attacks by requiring human interaction. Modern implementations are more sophisticated than the distorted text of past years, using invisible background challenges that don’t interrupt legitimate users. As is so often true, the core tradeoff is user experience. Every CAPTCHA adds friction. Invisible CAPTCHAs reduce this but may trigger more frequently for users with atypical browsing patterns, creating false positives. In much the same way as you can have differentiated rate limiting, you can apply CAPTCHAs selectively. A login attempt from a known device with good history is not challenged. An attempt from a new device showing bot-like behavior gets challenged. This provides security where needed while minimizing friction for trusted users. Another issue with CAPTCHAs is that LLMs are darn good at them. Don’t rely on them alone, but they can be part of a defense in depth strategy. Risk-Based Authentication Another, related, nuanced approach is risked based authentication. Rather than binary allow/deny decisions, risk-based authentication assigns a risk score to each login attempt based on many factors. (There is some overlap between this approach and some of the others mentioned above.) High-risk attempts trigger additional verification steps before access. Risk factors might include: a new device no, malformed, or expired cookies geographic location inconsistent with user history (as determined by IP to physical location mapping) unusual access time velocity of login attempts known compromised credentials a bad IP address, such as a TOR exit node or datacenter IP address The advantage of this approach is flexibility. Low-risk logins proceed smoothly while suspicious attempts get additional scrutiny. This balances security and user experience better than approaches that apply the same level of friction to everyone. However, this isn’t free. Building a robust risk scoring system into your login experience requires data collection, analysis, and ongoing tuning to avoid false positives. Plan to instrument your authentication system to track the necessary signals and build infrastructure to score them in real-time. Monitoring and Alerting If you are implementing credential stuffing defenses, build in monitoring and alerting to help you improve your system. Comprehensive monitoring is essential for both detecting attacks and tuning defenses. Key metrics to track include: support tickets related to account access issues MFA adoption and usage rates failed login attempt rate overall and per account distribution of login attempts across IP addresses and devices CAPTCHA solve rates and abandonment rate limit trigger frequency False Positive Management Every defense creates false positives. Legitimate users will occasionally trigger rate limits, fail CAPTCHAs, or exhibit suspicious behavioral patterns. The question is not whether false positives will occur (they will) but how you handle them. This requires: clear error messages that explain why access was restricted self-service recovery mechanisms when possible and (secure) responsive support teams for cases requiring human intervention tuning thresholds based on false positive data Track false positive rates just as carefully as attack detection rates. A defense that blocks attacks but also locks out, say, 5% of legitimate users causes more harm than good. Monetization and Business Impact Credential stuffing defenses are not just technical problems but business decisions involving tradeoffs between security, user experience, and costs. There are direct costs. Implementing defenses requires engineering time, infrastructure, and licensing fees for any third-party services. Bot detection services, CAPTCHA providers, and breach passwords databases all have associated costs. There are also opportunity costs. Authentication friction impacts conversion rates. Every additional step between a user and your service is an opportunity for abandonment. They’ll just stop trying to log in. Instrument your conversion funnels to understand the impact of security measures. This data can inform decisions about where friction is acceptable and where it’s too costly. Don’t sleep on support costs, either. Credential stuffing defenses generate support tickets from frustrated locked-out users, failed CAPTCHAs, and MFA setup issues. Budget for increased support volume when deploying new defenses. Implement these credential stuffing mitigations in phases to avoid overwhelming your support staff. Start by dogfooding it with employees or a subset of customers before a wider rollout. Balancing against costs is the value of prevented account takeovers. If possible, calculate the average cost of a successful account takeover, including fraud losses, customer support, potential regulatory penalties, and reputational damage. Even a modest reduction in successful attacks can justify significant investment. A credential stuffing attack that compromises 1,000 accounts may cost hundreds of thousands in direct losses and support costs. This doesn’t count harder-to-quantify reputation damage. What Makes Sense for Your Platform Not every platform needs every defense against these attacks. The right approach depends on your specific situation. If your platform has a few of these characteristics, invest heavily in credential stuffing defenses: Has a user base likely to reuse passwords, such as less technically sophisticated audience. Stores valuable user data or financial information. Has been targeted by attacks in the past. Provides functionality that attackers could monetize, such as cloud computing which can be used for crypto mining. Cannot afford reputational damage from breaches, such as a security or financial services firm. Conversely, some platforms face lower risk. A hobby project with minimal user data and no monetization might reasonably implement only basic rate limiting and password hygiene checks. Summing Up Defending against credential stuffing at scale requires layered security combining multiple complementary approaches. No single defense is sufficient. Each of the above options has flaws. Together, however, they create meaningful barriers for attackers. Consider the following elements and pick the ones that have the best protection with the least investment and user impact: multi-factor authentication to prevent account takeover even with valid credentials breach password detection to identify compromised credentials device cookies to distinguish trusted and untrusted clients rate limiting across multiple dimensions to slow down attackers risk-based authentication to balance security and user experience Pay attention to false positives and user experience. The goal is not perfect user account security, which is unattainable. Instead, focus on raising the cost of attacks until they become economically unattractive. Start with foundational defenses like rate limiting and breach password checking. Build from there based on measured risk and observed attack patterns. Invest in telemetry and monitoring to understand what’s happening. Credential stuffing is a persistent threat, but with thoughtful implementation of multiple defenses, you can protect your users while maintaining a positive experience for legitimate account access.