In a comment on my entry about common multi-factor authentication methods, Ben Hutchings said (in part):

I tend to think push-based approval is the least secure of the three. I've read several incident reports where the attacker got a user's password and then repeatedly tried to log in, spamming them with approval requests until they gave in and tapped Approve.

I've read similar reports (perhaps the same reports), so I believe that this MFA push notification fatigue is real, but I have questions because I don't understand how it actually works. Or, to put it another way, I don't understand how organizations set up (or break) their MFA environment such that it works.

In a sensibly set up MFA environment, I would assume that you don't get unsolicited, unprompted MFA requests out of the blue as an ordinary part of your ordinarily daily activities. Instead, you only get MFA requests if you're specifically doing something that needs authentication, such as logging in or sudo or whatever. I'd also expect the organization's authentication and MFA endpoints to require that a valid password be presented first (although if an invalid password was presented on a public endpoint, the endpoint might pretend it was doing an MFA prompt, to not provide an attacker a password validation service). I'd especially expect this to be required for anything that can be reached from outside the organization, by unauthenticated people on the Internet.

In this environment, getting a surprise MFA push request (or worse, several) out of the blue means that someone else has your password, which should cause you to hit some sort of big red security problem button to trigger at least a password change. It would also mean that if someone explicitly rejects one (or several) MFA push authentications, that should be a red alert to the security team (even if the person being spammed by notifications doesn't report it themselves). An MFA push notification might time out on its own for various reasons, but an active rejection is a very bad sign; it's the person telling you (the security system) that they did not make this request and actively rejected it.

(If your organization has internal, non-guarded endpoints that can trigger MFA push notifications without someone knowing your password, this at least means that someone is inside your network hitting those endpoints. That ought to be a security issue all by itself.)

Since MFA push notification fatigue is real (as Ben Hutchings mentioned), presumably one or more of these assumptions I'm making is wrong in these environments, either (or both) of the technical assumptions or the social assumptions of, say, there not being consequences to you of reporting that your password has been compromised (or just quietly changing it).

(Although common MFA push notification systems are provided by third party companies and so might be used by multiple organizations that you have accounts with, I believe that they tell you who is requesting a push authorization. Hopefully in some way that can't be forged by another customer, even if they allow customers to supply some text to be shown to you.)

PS: Although it's not push notification fatigue itself, having an organizational setting that you will lock someone's MFA after N failed requests is rather dangerous. If I've gotten N-1 MFA push notifications that I've ignored or rejected, I know that I am about to get locked out if I say no to the next one. That may force me to roll the dice on whether this is an attacker trying to get me to say yes or something gone wrong in our systems that is triggering unexpected MFA challenges. The harder it is to get my MFA unlocked and the more unpredictable my organization's MFA handling is, the more I may be likely to take the risk.

(I think what you want is for each service or MFA endpoint to have its own separate token or other authorization signature, and when you see N MFA failures from a particular service, you only lock out that user on that service. A global user lockout should only be triggered if you have high confidence that the user's password must have been compromised, based on the services that are failing to pass MFA.)