MFAPushFatigueQuestions

By admin
In a comment on my entry about common multi-factor authentication methods,

Ben Hutchings
PERSON

said (in part):

I tend to think push-based approval is the least secure of the

three
CARDINAL

. 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
ORG

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
ORG

environment such that it works.

In a sensibly set up

MFA
ORG

environment, I would assume that you don’t get unsolicited, unprompted

MFA
ORG

requests out of the blue as an ordinary part of your ordinarily

daily
DATE

activities. Instead, you only get

MFA
ORG

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
ORG

endpoints to require that a valid password be presented

first
ORDINAL

(although if an invalid password was presented on a public endpoint, the endpoint might pretend it was doing an

MFA
ORG

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
ORG

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
ORG

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
ORG

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
ORG

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
ORG

push notification fatigue is real (as

Ben Hutchings
PERSON

mentioned), presumably

one
CARDINAL

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
ORG

push notification systems are provided by

third
ORDINAL

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
ORG

after

N
ORG

failed requests is rather dangerous. If I’ve gotten

N-1 MFA
PRODUCT

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
ORG

challenges. The harder it is to get my

MFA
ORG

unlocked and the more unpredictable my organization’s

MFA
ORG

handling is, the more I may be likely to take the risk.

(I think what you want is for each service or

MFA
ORG

endpoint to have its own separate token or other authorization signature, and when you see

N MFA
ORG

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
ORG

.)