Phishing-proof MFA stops Uber push fatigue

MFA fatigue only works when the second factor is an Accept button someone can tap under pressure. Uber’s September 2022 contractor incident was that path: a known password plus repeated two-factor approvals until one was accepted. Phishing-proof MFA 2.0 removes the spam-able prompt, so password possession alone cannot finish workforce login.

Would phishing-proof MFA 2.0 have stopped Uber’s 2022 contractor MFA fatigue login? At the credential phase, yes. According to Uber’s Newsroom security update on 19 September 2022, an EXT contractor’s corporate password was likely bought after malware on a personal device exposed it, then the attacker repeatedly triggered two-factor login approval requests until the contractor accepted one and a real session was issued. Device-bound MFA 2.0 has no approve/deny prompt to flood and requires an origin-bound cryptographic signature from an enrolled device, so that push-bombing path fails before a workforce session exists. What followed in Slack, G-Suite, and other internal tools was post-authentication abuse of access already granted. No login MFA undoes that residual stage. For the full attack-chain narrative, read the companion on legacymfa.sucks.

FAQ

Would MFA 2.0 have stopped the Uber contractor push-fatigue login?

Yes. The Uber 2022 contractor login was a credential-phase MFA fatigue attack, and phishing-proof MFA 2.0 is built to stop that path. Uber stated the attacker held the contractor’s corporate password and repeatedly tried to log in until a two-factor approval request was accepted. Legacy push MFA still completes when a human taps Accept. MFA 2.0 replaces spam-able approve/deny prompts with device-bound public-key signatures. There is no transferable push to fatigue, and a remote attacker with only a password cannot mint a valid workforce session. Closing that phishable login stops this path. Malware after a legitimate login is a harder, separate problem.

Why does approve/deny push MFA fail against push bombing?

Approve/deny push MFA fails against push bombing because the second factor is still a human decision on a known password, not a hardware-bound proof. In the Uber contractor case, each login attempt generated a two-factor approval request that initially blocked access, until one acceptance issued a legitimate session. The attacker did not need to break cryptography. They only needed patience and a tired contractor. That is why legacy MFA was dropped as a prevention model for workforce login: a factor you can spam until someone taps Accept is still phishable under social pressure.

Are passkeys enough for an Uber-style MFA fatigue path?

Passkeys harden the login act and are phishing-resistant at authentication, which already beats approve/deny push against remote fatigue. MFA 2.0 goes further as phishing-proof coverage across the identity lifecycle, not only the sign-in ceremony. For Uber’s documented path, the decisive failure was a spam-able push on a stolen password. A device-bound, origin-bound signature with no approve prompt removes that failure mode at login. Public reporting does not establish a separate enrollment or recovery compromise in this incident, so the prevention claim here is the login factor itself, not a helpdesk re-enrollment story.

What does MFA 2.0 not undo after the Uber session existed?

MFA 2.0 does not undo post-login reach into other employee accounts, Slack, G-Suite, OpenDNS changes, finance-invoice-tool data, or a HackerOne dashboard once a valid workforce session already exists. Uber reported those internal effects after the contractor login succeeded, and also reported no evidence of access to production user databases or sensitive user financial data. Containing that stage needs session revoke, privilege limits, and detection. That is residual hygiene, not the prevention claim. The prevention model is stopping the fatigue login so the internal session is never issued by that path.

How should enterprises harden contractor logins against MFA fatigue?

Enterprises should remove approve/deny push and other transferable second factors from contractor and workforce login, and require device-bound cryptographic MFA that cannot be completed by tapping Accept on a flood of prompts. Uber’s own update said it further strengthened MFA policies after rotating access and forcing re-authentication when restoring internal tools. Password exposure on a contractor’s personal device still matters for hygiene, but it should not be enough to finish corporate sign-in. If the second factor has no prompt to fatigue and the private key never leaves the enrolled device, the Uber-style push-bombing path dies at the login boundary.