MFA Fatigue Attacks: Defending Against Push Bombing

The narrative around multi-factor authentication (MFA) fatigue attacks often centers on the user's failure to exercise caution. This is a misdiagnosis. The vulnerability is not a lack of vigilance but a fundamental flaw in the design of push-based notification systems: they decouple the authentication event from the user's explicit intent. When an attacker initiates a login with stolen credentials, they do not need to break the cryptographic handshake. They only need to trigger a notification. If the victim, bombarded by hundreds of prompts, eventually taps "Approve" out of frustration, the attacker bypasses the second factor. This is a denial-of-service attack against cognitive processing capabilities.

This guide explores the mechanics of these attacks and the architectural shifts required to neutralize them. Part 8 of the Passwordless & Next-Gen Authentication Series details how to shift from user-centric verification to device-centric attestation and behavioral analysis.

Mechanism of the Push Bombing Loop

The mechanism of a push bombing attack is a high-volume loop. An attacker obtains a valid username and password, often through a credential stuffing campaign or a data breach. They then script an automated process to hit the identity provider's authentication endpoint repeatedly. For each attempt, the system generates a unique push notification payload and sends it to the registered mobile device.

Consider an attacker named "Vanguard" targeting a user named "Alice." Vanguard scripts a loop that sends 500 authentication requests per minute. Alice's phone vibrates continuously. The screen flashes with "Sign-in attempt: Do you recognize this?" The cognitive load spikes. Alice is likely at work, trying to focus, or perhaps in a meeting. The sheer volume creates a state of sensory overload. Eventually, Alice's brain switches to a heuristic mode: "It's annoying, just make it stop." She approves the notification. Vanguard's script captures the success token and gains entry. The cryptographic signature of the MFA challenge was valid; the user interaction was coerced by volume.

The Psychology of Approval Fatigue

This phenomenon relies heavily on "approval fatigue." Human beings are not designed to distinguish between a legitimate, low-frequency authentication request and a malicious, high-frequency bombardment when the interface is identical. The standard push notification UI presents a binary choice: Approve or Deny. It lacks nuance. It does not ask "Is this request part of a flood?" or "Did I initiate this?" It simply asks "Do you want to log in?"

Under normal conditions, the answer is "Yes." Under bombardment, the answer becomes "Whatever stops the noise." Studies on notification fatigue indicate that users are significantly more likely to approve suspicious MFA requests when they are presented in rapid succession, a behavior known as the "urgency bias" induced by notification fatigue. The interface fails to provide context regarding the source or the nature of the request volume, leaving the user to rely on a broken heuristic.

Protocol-Level Defense: Number Matching

To defeat this, we must change the mechanism of verification. The industry standard for mitigating push bombing is "Number Matching." In a traditional push flow, the notification contains a generic message. In a Number Matching flow, the authentication server displays a random number (e.g., "8492") on the login screen where the user is entering their password. The push notification on the mobile device displays the same number. The user must type that specific number into the app to confirm.

This breaks the correlation that allows the attacker to succeed. If Vanguard bombs Alice with 500 requests, Alice sees 500 different numbers on her phone screen (e.g., 1023, 4921, 8832) and 500 different numbers on her computer screen. She cannot guess the correct pair. She sees that none of the numbers match her own intent, or she realizes she didn't initiate any of them. The "Approve" button becomes useless because the user cannot satisfy the condition without knowing the specific number displayed on the device she is holding.

{
  "challenge": {
    "display_number": "8492",
    "session_id": "sess_7f8d9a2b",
    "expires_in": 30
  },
  "user_input": "8492"
}

Behavioral and Device Hardening

However, relying solely on Number Matching is insufficient if the underlying infrastructure allows unlimited request flooding. We must implement behavioral defenses at the Identity Provider (IdP) level. This involves Risk-Based Conditional Access. The IdP should monitor the rate of authentication requests originating from a single source IP or associated with a specific user session. If the system detects a spike in requests—say, more than 5 per minute from a non-whitelisted IP—it should trigger a "Challenge Response" or "Block" policy before the user's device is even notified.

Consider a scenario where Vanguard attempts to bomb Alice. The IdP sees 100 requests from a proxy server in Eastern Europe for Alice's account in the US. The policy engine, configured with anomaly detection, flags this as "Impossible Travel" combined with "High Volume." Instead of generating push notifications, the system blocks the requests entirely and logs an alert for the security operations center (SOC). The user never sees the notifications. The attack vector is closed at the network layer, not the cognitive layer.

Furthermore, organizations must enforce device attestation. Modern mobile operating systems provide APIs to verify the integrity of the device receiving the push notification. If the device is rooted, jailbroken, or running unauthorized software that might be intercepting the notification stream, the IdP can deny the authentication attempt. This adds a layer of trust that the notification is reaching a genuine, unmodified user environment. Additionally, limiting the "time-to-live" (TTL) of a push notification is critical. A valid authentication request should expire within 15 to 30 seconds. If an attacker is flooding the device, the window for a user to accidentally approve an old, stale notification should be non-existent. The system must ensure that the notification displayed on the phone corresponds to the most recent request initiated by the user, not a backlog of stale requests.

The Future of Attestation: FIDO2

The ultimate defense, however, is to eliminate the push notification mechanism for high-risk scenarios entirely. Push notifications are inherently susceptible to this type of fatigue attack because they rely on a "passive" user action (tapping a button) rather than an "active" cryptographic proof. Phishing-resistant MFA methods, specifically FIDO2 (Fast Identity Online) keys, solve this by binding the authentication to the device hardware itself.

In a FIDO2 flow, the browser or app generates a cryptographic challenge. The private key, stored securely in the device's Trusted Execution Environment (TEE), signs this challenge. The signature is mathematically impossible to forge without the key. Crucially, the FIDO2 protocol includes the relying party's domain in the signature. If an attacker tries to use a stolen credential on a malicious site, the signature will fail because the domain doesn't match. There is no "Approve" button to fatigue. There is no notification to bombard. The user must physically touch the device (biometric or PIN) to release the key. This shifts the burden of security from the user's attention span to the device's cryptographic integrity.

# Example FIDO2 assertion generation flow
server.generate_challenge()
# Challenge signed by private key in TEE
assertion = authenticator.sign(challenge, domain)
# Verification includes domain binding check
verify(assertion, public_key, domain)

Conclusion

For organizations still relying on push notifications, a layered approach is mandatory. First, mandate Number Matching for all users. Second, configure aggressive rate-limiting and anomaly detection in the Identity Provider to prevent the flood from reaching the device. Third, educate users that "Approve" is a dangerous action when notifications are frequent; they should be trained to deny any request they did not explicitly initiate, regardless of the noise. Finally, prioritize the migration to FIDO2 standards for privileged accounts.

The mechanism of MFA fatigue attacks reveals a dangerous assumption: that the user is the final gatekeeper. In a push bombing scenario, the user is not a gatekeeper; they are a bottleneck. By overwhelming the bottleneck, the attacker bypasses the gate. Defending against this requires removing the user from the decision loop for high-volume events and replacing it with deterministic, cryptographic, and behavioral controls. The goal is not to make the user smarter, but to make the system smarter.

Practical Takeaways

To defend effectively against push bombing, adopt these mental models:

1. The Noise Principle: Treat rapid-fire notifications as a denial-of-service attack, not a series of independent login attempts. The volume itself is the threat vector.
2. Context is King: A notification without context (like a specific number to match) is insufficient for high-stakes authentication. Always require out-of-band confirmation tied to the specific session.
3. Layered Defense: Never rely on a single control. Combine protocol-level fixes (Number Matching) with infrastructure controls (Rate Limiting) and user education for a resilient posture.

FAQ

Q: Can I disable push notifications entirely to stop these attacks? A: You can disable them for specific high-risk accounts, but this may impact user experience. A better approach is to enforce Number Matching, which neutralizes the attack while retaining the convenience of push notifications.

Q: Does enabling Two-Factor App (2FA) apps like Google Authenticator prevent push bombing? A: Yes, Time-based One-Time Passwords (TOTP) are immune to push bombing because they do not rely on an incoming notification. However, they are susceptible to phishing if not paired with domain binding or FIDO2.

Q: How many notifications constitute a "bombing" attack? A: There is no fixed threshold, but typically fewer than 5 requests per minute from a new location or device triggers a risk flag. Automated scripts can easily exceed 50 to 100 requests per minute, creating the fatigue condition.