I have been searching resources online about proper MFA/2FA (with O365 specifically) considerations.

How is the MFA push challenge notification to Approve or Deny a sign-on not dangerous? I have yet to find any articles stating this. Most I see is how TXT based is no good.

Example with the Approve/Deny type of MFA: If a threat actor types in your credentials - your phone will get an Approve or Deny request. One of our end-users today got a fake "Check your VM" spam message - she clicked on this message, it took her to a fake O365 Login page, she typed in her creds, a few seconds later she got an Approve or Deny request - she Approved thinking she was logging into O365- 2 minutes later we got a notification that the same user tried to log in from Russia -- immediately disabled and revoked all sessions.

Can someone explain to me how this MFA approval method is OK? this would never work with TXT or authenticator code sign on. (you need to input the proper codes into the site to proceed to log on) Not to mention that the average user will just click 'approve' randomly thinking their Phone, tablet, or PC needs to approve again.

What am I missing here?


2 Answers 2


A non-discriminating user who doesn't check URLs on login forms WILL fail MFA.

I run internal security scans & testing at my company, including the dreaded staged phishing tests. One of my scam login pages is tied to a bot that immediately uses the entered credentials to login & get a persistent-use token in the background. If our user has MFA enabled (and they all should) then my page presents the MFA code input box and passes that to the real site too. It's an easy catch (the domain in the URL is badly misspelled), but MFA alone doesn't work when the user is the one typing in info. That isn't what MFA is designed to do.

I want everyone to repeat after me. Nothing will stop a bad guy who gets one of your users to willing give them an interactive login. In that scenario your user is the weak link, not the authentication system.

What MFA does is protect the user/account should their password be broken through other means (password cracking or password disclosure). So the bad guy has your user's password but can't use it because they don't have the ability to pass the MFA check (entering a OTP, presenting a hardware security token, acknowledging a push notification on a device). And, ideally, you user will report the security concern when they begin receiving unexpected MFA prompts on their device.

But if the bad guys get your user to play along -- then no level of MFA will stop them. Because, yes, the user can hit the "allow" button on the push notification to the authenticator app. They can also type in a RSA SecureID fob code [TOTP], or insert their hardware token [FIDO/WebAuthn/SmartCard] into the computer and click "OK". If your authorized user is helping the bad guy, then the bad guy will get in. And that isn't a problem with the authentication system.

That's why it is EXCEEDINGLY important to have good cybersecurity training (and testing, with remedial training for failures) for all of your users. The users are often the weakest link (as your person proved). But if you train them to exercise just a little bit of skepticism and to "trust but verify" then you'll avoid these incidents in the future.

  • 1
    I agree for the classic case of a password + unidirectional one time code (Yes/No prompt, SecureID, other hardware tokens generating codes...) However, FIDO/WebAuthn won't. These are designed to depend on the url (site), so even if the user doesn't check URLs on login the token itself does! Authentication with client certificates is also immune, since the authentication is linked to the TLS negotiation, and it can't be replayed.
    – Ángel
    Commented May 14, 2023 at 1:47

It would probably have worked with an authenticator code as well: your end-user enters the code in the fake login page which enters it in the real login page right after and gains access.

However, MFA will prevent anyone possessing only your login/password to authenticate (you need both factors at hand).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .