In September 2022 an attacker who had bought an Uber contractor’s password tried to log in again and again. Each attempt sent the contractor a two-factor approval request. The first ones blocked the attacker. Then one was accepted, and the attacker was in (Uber’s security update). A month earlier, Cisco described the same pattern in its own breach: voice calls from someone posing as support, and a stream of push requests until an employee accepted one (Cisco Talos).
Both companies had multi-factor authentication switched on. The attackers did not crack the second factor; they walked around it, using techniques that work because the MFA in place asks a tired human to make a security decision at the worst possible moment.
If your MFA is an SMS code or a one-tap “Approve?” push, this is worth ten minutes of your attention. Those two methods are now the ones attackers plan around, not the ones that stop them.
Three attacks that beat “some MFA”
- Push-bombing (MFA fatigue, MFA bombing, 2FA bombing). The attacker already has the password (from a breach dump, a phish, or reuse). They trigger login after login, firing a stream of approval prompts at the user’s phone until, out of confusion or just to make it stop, someone taps Approve. One tap and they are in.
- SIM swapping. SMS was never designed as a security channel. An attacker who convinces (or bribes) a mobile carrier to move a number to a new SIM receives every one-time code sent to it. No malware, no phishing page — just a phone call to a support desk.
- Adversary-in-the-middle (AiTM). A convincing fake login page proxies the real one in real time. The victim enters their password, the real system asks for the second factor, and the victim provides it, because they really are trying to log in. The attacker’s proxy collects the resulting session. The MFA “worked.” The account is still gone.
The US cybersecurity agency CISA names all three in its guidance and draws a clear line: only FIDO/WebAuthn and public-key (PKI) authentication count as phishing-resistant, because the key is tied to the real website’s address and a look-alike page cannot use it. Push approval, even with number matching, is not on that list (CISA fact sheet).
What stops each one
These attacks have different weak points, so it is worth being precise about what defeats which.
- SIM swaps and code interception: remove the code. If the user’s key is generated in the phone’s secure hardware and never leaves it, there is no shared secret in a database and nothing arriving over SMS. There is nothing to intercept, and moving a phone number moves nothing an attacker can use.
- Push-bombing: let the user read what they are approving. No key and no biometric helps once a request reaches the phone, because the attack simply asks the user to say yes. A biometric only confirms the phone’s owner is the one tapping, not that the login is legitimate. What works is a request that carries a specific, readable description of exactly what is being approved: which service, which action, from where. A prompt the user never initiated is visibly not theirs, so they decline it. Request expiry and limits on how often prompts can be triggered take away the volume the attack depends on.
- Adversary-in-the-middle: approval alone does not stop it. Here the user is not tricked into approving someone else’s login. They approve their own, on the wrong website. What helps is showing where the request came from: if the approval names the address the login arrived from, a proxy in another country stands out to a user who looks. That raises the cost of the attack; it does not make it impossible. Where the threat model calls for phishing resistance in the strict sense, site-bound FIDO keys are the answer, alongside short session lifetimes and sign-in policies that limit where sessions can be used.
That is the difference between MFA that an attacker has already scripted past and MFA that makes each of these attacks visible or pointless.
Where Notakey fits
Notakey removes the code and makes every approval readable.
- The user’s key is generated inside the phone’s secure hardware and never leaves it. There is no SMS to intercept and no code to relay.
- The notification is only a doorbell. When the user opens the app, it fetches the approval card over HTTPS from the server it was enrolled with, so what the user reads comes from your server, not from the notification, and their signature covers that exact request.
- Against push-bombing, the defense is what the user reads: the card shows which service is asking and what is being approved, so a prompt nobody initiated is obvious on sight and gets declined. Requests expire, and a built-in limiter caps how often they can be triggered, so the stream of prompts the attack relies on is cut short.
- Against adversary-in-the-middle, the server can be configured to put the requesting IP address, service name or URL on the card, so the user sees where the login is actually coming from. We will not claim more than that: it makes a proxy visible to a user who looks; it does not make the attack impossible.
- It covers the paths attackers actually use; see the practical guides for 2FA on a VPN over RADIUS, Windows remote desktop and Linux SSH.
See it for yourself
The quickest way to feel the difference is to approve a transaction you can actually read: a specific action, signed from your own phone, rather than a context-free prompt.
Try the live demo to sign one in about two minutes, or request a demo and we will map your VPN, SSO or Windows logins to a pilot on your own infrastructure.