Alright, folks, Pat Reeves here, live from my slightly-too-caffeinated desk at botsec.net. Today’s date is May 14, 2026, and I’ve been wrestling with a particular flavor of bot-related headache that I think many of you are either experiencing or are about to. We’re talking about the escalating war against credential stuffing bots, specifically how they’re bypassing what should be robust authentication flows. It’s not just about having MFA anymore; it’s about the entire user journey, from initial login to session management.
For years, we’ve preached the gospel of strong passwords and multi-factor authentication (MFA). And don’t get me wrong, those are still foundational. But what happens when the bots get smarter? What happens when they’re not just trying a list of stolen credentials against a single login page, but systematically probing an entire ecosystem of services, often exploiting weaknesses in the very MFA mechanisms we rely on?
I recently spent a week consulting with a mid-sized SaaS company – let’s call them “WidgetCo” – who were getting absolutely hammered. They had implemented a decent MFA solution, using TOTP (Time-based One-Time Password) codes. Their initial assessment was, “Our MFA is strong, the breaches must be elsewhere.” But the user complaints piled up: “My account was accessed even with MFA enabled!” “I got an MFA prompt I didn’t initiate!” It was a mess, and it pointed directly to a sophisticated credential stuffing operation that wasn’t just guessing passwords; it was actively trying to complete the MFA challenge.
The Evolving Threat: More Than Just Login Pages
The classic credential stuffing attack involves bots taking a list of usernames and passwords, often from a dark web dump, and systematically trying them against a target website’s login form. If a match is found, great, account compromised. But that’s the amateur hour stuff now.
Today’s bots are smarter. They’re often distributed across vast networks of residential proxies, making IP-based blocking a game of whack-a-mole. They employ advanced CAPTCHA bypass techniques, sometimes even using human farms on demand. And critically, they don’t stop at the password field.
WidgetCo’s problem wasn’t their password policy. It was that their MFA implementation, while standard, had a few subtle vulnerabilities that sophisticated bots were exploiting. The bots weren’t just trying to guess the password; once they hit a valid username/password combo, they were then trying to complete the MFA step, often by triggering repeated MFA requests to the legitimate user’s device.
The “MFA Fatigue” Attack
This is where it gets nasty. The bot successfully enters a stolen username and password. The system then sends an MFA prompt to the legitimate user. The user, seeing an unexpected prompt, might dismiss it. But what if the bot tries again? And again? And again? This is “MFA Fatigue.” The bot spams the user with prompts, hoping that either the user eventually accepts one by mistake, or gets so annoyed they block notifications, inadvertently making subsequent attacks easier.
At WidgetCo, this was happening. Users were getting dozens of MFA prompts, sometimes in the middle of the night. Some, groggy and annoyed, might have tapped “Approve” just to make it stop, thinking it was a glitch. Others just started ignoring all prompts, which is equally dangerous.
The bots were also using social engineering. They’d initiate an MFA prompt, then immediately try a password reset. If the user was already fatigued, they might not scrutinize the reset email as closely. It was a multi-pronged assault.
Beyond Basic MFA: Building a Bot-Resistant Auth Flow
So, how do we fight back when the bots are playing dirty?
1. Rate Limiting on MFA Requests – The Obvious, Yet Often Missed
WidgetCo had basic rate limiting on password attempts. They had none on MFA requests. A single bot could trigger hundreds of TOTP code prompts for a single user in minutes. This is a fundamental oversight.
Implement strict rate limits not just on login attempts, but on successful password validation followed by MFA request generation. For example, allow 3 MFA requests per minute per user, then block for 5 minutes. After 5 blocks, escalate to a longer lockout or a more intensive challenge (e.g., a hard CAPTCHA or even human review).
// Example (simplified pseudo-code for a backend MFA request handler)
function requestMFA(userId) {
const mfaRequests = getMFAAttemptsInLastMinute(userId);
if (mfaRequests.count >= 3) {
logSecurityAlert(userId, "MFA_RATE_LIMIT_EXCEEDED");
return { success: false, message: "Too many MFA requests. Please try again later." };
}
// ... proceed with sending MFA code ...
incrementMFAAttempts(userId);
return { success: true, message: "MFA code sent." };
}
This simple step alone drastically reduced the MFA fatigue attacks at WidgetCo. It made it impossible for a bot to spam a user into submission.
2. Contextual MFA Challenges – Knowing Your Users (Sort Of)
Not all login attempts are equal. A user logging in from their usual device, at their usual time, from their usual geographic location, should have a smoother experience than someone logging in from a brand new IP address in a different country at 3 AM.
This is where contextual authentication comes in. Instead of always prompting for MFA, or always just accepting a password, introduce risk scoring. If a login attempt is low-risk, maybe skip MFA or use a less intrusive method (like a push notification approval). If it’s high-risk, enforce a full TOTP or even a biometric challenge.
- New Device/Browser Detection: Track user agents, cookies, and browser fingerprints. If a login comes from a new device, always prompt for MFA, even if the password is correct.
- Geographic Anomaly Detection: If a user typically logs in from London, and suddenly there’s an attempt from Jakarta, flag it. Force MFA, or even temporarily block the login and notify the user.
- Time-of-Day Anomalies: While less definitive, an attempt at 3 AM for a user who typically logs in during business hours could be a flag.
This makes the bot’s job much harder. They can’t just replay credentials; they need to emulate a legitimate user’s entire browsing environment, which is significantly more resource-intensive.
3. Implementing “Number Matching” for Push-Based MFA
If you’re using push notifications for MFA (like many popular authenticator apps), you’re still vulnerable to the “Approve/Deny” fatigue. The user just taps “Approve.” They don’t know if they’re approving their own login or a bot’s.
The solution? Number matching. When the user tries to log in, the application displays a unique, short code (e.g., three digits). The push notification then asks the user to enter that specific code into their authenticator app to approve the login. This forces the user to actively verify the login attempt, making it much harder for a bot to trick them.
// Frontend login flow (simplified)
// User enters username/password, hits submit
// Backend validates password, generates a random 3-digit code
// Backend sends push notification with a prompt like: "Enter code 123 to approve login."
// Frontend displays: "Check your device for a security code. Enter 123 into your authenticator app to continue."
// Authenticator app logic (simplified)
// Receives push notification
// Displays "Login attempt for [Service Name]. Enter code: [field to enter 3 digits]"
// User enters 123
// App sends approval with the entered code back to the backend
This is a game-changer for push-based MFA. It adds a crucial layer of user interaction that bots simply can’t automate without direct human intervention.
4. Session Management and Revocation – The Aftermath
What happens if a bot *does* get in? Your defenses should extend beyond the login page.
- Session Invalidation on Password Change: If a user changes their password, all active sessions (except perhaps the current one, after re-authentication) should be immediately invalidated. This prevents an attacker who somehow got a session token from continuing to access the account after the legitimate user has secured it.
- Active Session Monitoring: Provide users with a list of their active sessions (device, location, last accessed). Allow them to revoke any suspicious sessions. This empowers users to take control and acts as an early warning system.
- Short-Lived Session Tokens: For high-privilege operations, use shorter-lived access tokens and longer-lived refresh tokens. If an access token is compromised, the window of opportunity for the attacker is smaller.
WidgetCo initially had sessions that lasted for weeks without re-authentication, even after a password reset. This meant if a bot got in, it could stay in for a long time. Shortening session lifetimes and adding revocation capabilities was a critical fix.
Actionable Takeaways for Bot-Resistant Auth:
- Audit Your MFA Rate Limits: Don’t just rate limit password attempts. Critically, rate limit MFA request generation per user.
- Implement Contextual Authentication: Use signals like device, location, and time to assess login risk and adjust MFA challenges accordingly.
- Upgrade Push MFA to Number Matching: If you use push notifications for MFA, move to a system where users must enter a displayed code. This is significantly more secure against fatigue attacks.
- Strengthen Session Management: Invalidate sessions on password changes, offer users the ability to review and revoke active sessions, and consider shorter-lived access tokens.
- Educate Your Users: Inform them about MFA fatigue attacks. Tell them *never* to approve an MFA prompt they didn’t initiate. Explain what to do if they see suspicious activity.
The bots are getting smarter, but so can we. Protecting your users isn’t just about throwing MFA at the problem; it’s about understanding the evolving tactics of attackers and building a layered, intelligent defense. Stay vigilant, stay secure, and keep those bots out of your systems.
🕒 Published: