back to article Microsoft disarms push notification bombers with number matching in Authenticator

Microsoft is hoping to curb a growing threat to multi-factor authentication (MFA) by enforcing a number-matching step for those using Microsoft Authenticator push notifications when signing into services. Starting this week, Redmond is putting some muscle behind a number-matching feature that it began talking about last year. …

  1. Anonymous Coward
    Anonymous Coward

    Security vs Convenience

    Is it really that difficult to enter in a 6 digit number?

    I’ve never liked the push notification form of 2FA for the sole reason it’s just a matter of time before someone accepts the authentication unwittingly while in a nice safe environment with their legs up and hair down, possibly even a wee bit drunk.

    Needing to enter in a code negates any possibility of any miscreants with your password spamming you with “push notifications”

    Also, more worryingly still, if an end user is being spammed with 2FA push notifications that should be alarm bells to them and they should probably take it as a given that their password has been compromised.

    Assuming they piece this information together.

    If your employees do not make this connection, that’s idiotic

    1. Sora2566 Silver badge

      Re: Security vs Convenience

      Yes, but sometimes all an attacker needs is one idiot. Hence the attempt at idiot-proofing.

      1. Dan 55 Silver badge

        Re: Security vs Convenience

        If you want idiot proofing take the idiot out of the equation. Don't use push notifications (i.e. use TOTP) and the system should flag accounts that have repeated successful password entries but keep failing on 2FA.

        1. Anonymous Coward
          Anonymous Coward

          Re: Security vs Convenience

          When the credential stuffer tries to log in, the push notification is, in a way, a direct communication between you, and whoever is somewhere in the world, currently interfacing with something like a web login using your credentials.

          Remove push notifications and use the classic MOTP

          That way the end user is not spammed with ill-thought out-solution-looking-for-a-problem-push-notification-2FA

          Entering in 6 numbers is not hard

          1. Psion1k

            Re: Security vs Convenience

            The problem with MOTP is that the seed can be present on multiple devices (and could technically be read programatically without the user knowing), so the Push method is considered more secure. Push is also required to satisfy 'impersonation resistance' (but not necessarily all that is needed), which itself requires that the user enters nothing for the authentication process into the target system, beyond a username and (optionally) a password.

            OTP of any sort is better than no MFA, but generally Push is a better security option. The specific combination of a particular device receiving the request and the user having to enter a counter-code into the same device that can only be visually read from from the requesting system bolsters security immensely. It literally becomes next to impossible (without social engineering) to get a throw-away MFA approval.

      2. seven of five Silver badge

        Re: Security vs Convenience

        attempts to idiot-proofing will result in better idiots.

    2. Dave K

      Re: Security vs Convenience

      Part of the problem can be when multiple services are set up to require 2FA approval. When they first introduced it where I work, there was 2FA for logging into Windows, 2FA for connecting to VPN, 2FA for Outlook, 2FA for Yammer, etc. In short, staff were used to being hit with numerous 2FA approval requests, so if another one comes through its easy to assume it must be for Sharepoint or something and just tap "approve".

      Now, my workplace has largely fixed the mass of 2FA approvals thankfully, but it does show that someone can approve a nefarious request quite innocently, depending when it arrives and how their organisation's security is set up.

      Anyway, the addition of the code makes a lot of sense here - I certainly agree with you there!

    3. Adam JC

      Re: Security vs Convenience

      I'm actually all for number-matching over the previous 'Approve / Reject' style prompt.

      It's only 2 digits, not 6 and it completely removes the possibility of someone inadvertently jabbing 'Approve' without bothering to engage their brain. I can't see any argument against it to be honest, it now means if someone's 365 credentials are compromised, the number prompt has to be retrieved from the end-user by the attacker as well which hugely complicates the process.

    4. ACZ

      Re: Security vs Convenience

      Exactly - if I'm logging into a system then just present me with a screen asking for a one time passcode from my authenticator app. It's not difficult and only takes a couple of seconds. The system should fail safe, and push notifications requesting approval are the total opposite.

      The problem here is push notifications per se, not user fatigue.

  2. ExampleOne

    If the problem is bad actors spamming users with authentication requests till they approve the access, why not implement rate limiting on the accounts?

    1. Sora2566 Silver badge

      Even if they do it once an hour, if they do that every hour for a whole week...

    2. Anonymous Coward
      Anonymous Coward

      Need to be able to ban/block the attacker not slow them down

      That said the server side should be rate limiting repeated requests. Push codes were another idea from the room temp IQ set, probably the ones who were already butthurt about their idiotic SMS implementations being torn to shreds.

      Most of this still comes down to implementation problems. Existing push authentication windows focus on mobile devices. They use tiny totifications that are hard to read, last only seconds, and rarely let the user go back and review missed alerts or change their response and revoke an accidental approval. They provide no channel to report a spamming attack, either to the service the request is for, your employers IT department, or law enforcement.

      Apple and Google are about as bad in this regard, and all three seem content with the garbage they made because the other two are doing the same thing. All of this is the long shadow of SMS codes, which were literally only chosen because they wanted to force users to cough up a working mobile number.

      Adding MITM protections to TOTP would have been easier and allowed offline authentication. Instead we built yet another standard and it has more problems than what it replaced.

      Passkeys will help with this, but we need to make sure that stays open so we don't end up with another "you can use any SSO provider you want as long as it's Google or Azure" problem.

      FIDO keys are also solid but have some rough edges in the user experience and almost nothing supports them currently.

      I think we also need to force providers the require authentication to support an open and user controlled method. By that I mean that when I sign up for service X, I should be able to tell them what authentication methods to use. If I want TOPT, no security questions, and a FIDO keyring, that's what I should get. If someone else wants a public key and a push codes, and for their aunt Georgina to be able to reset their access, that should be what they get. Linux got 85% of the way there with PAM modules. Site operators should be able to define minimum standards and everyone should be required to use an upgrade-able security plugin that is separate from the underlying OS so flawed methods can be fixed, revoked, or replaced on the fly.

  3. Pascal Monett Silver badge

    Human weakness at work again

    "eventually accept the login to stop the harassment"

    What ? No.

    The fact that there is harassment is a clear sign that a takeover attempt is active. That is not the time to just click Yes so that you can make another post on Twitter.

    That is the time to contact your provider and warn them that a takeover is occuring.

    Of course, it would help if you have another platform than your smartphone to do so . . . so basically only only anyone over 40 can hope to be able to respond properly.

    1. Anonymous Coward
      Anonymous Coward

      Give them a report and block button then

      And make sure they can view the list of past requests and revoke an accidental yes if they fat finger it pulling their phone out of their pocket.

      1. tiggity Silver badge

        Re: Give them a report and block button then

        @AC The whole UI design of authenticators is dire - as you say easy to "fat finger" mistype, usually no way to review / revoke recent acceptances, normally no hint as to which "site/app" the authentication request is for (some workplaces use SSO, but others its a different sign on for each "site/app" & a barrage of authentication requests & play guessing game of which one this authentication request is for). At least when a number needs entering there is no chance of a fat finger failure as not going to accidentally enter code number when accessing the app.

  4. WolfFan

    Hmm.

    MSA has been asking me to enter a number to auth for months now. Every single time I log into certain services at certain sites I must dig out the phone and enter the auth number. Even if I have already logged into that site, but for a different service. Example: I do adjunct instruction for a local college. If I log into Canvas, the Learning Management System (don’t ask, you don’t want to know) I must use MSA. If I log into web-based email (OWA) I must use MSA. If I log into Workday, I must use MSA. Even if I am already logged into one or more of the services. It’s very annoying. Especially when Workday times out a few hours later, well before OWA or Canvas, and I have to log in again. Despite being already logged in. And despite having just spent hours in Workday. Urge to kill sets in.

    1. Screepy

      Re: Hmm.

      I'm not sure this is the fault of the authentication type though.

      That is just a time limit implemented by the admins when they set up the application, in your case Canvas/ Workday.

      There is usually a setting in the config of the app for how long an auth session will last - controlled by the sys admins obviously.

      At least that is how a number of our applications were set up with when we added 2FA - we could set timeouts from minutes to hours to days, or just x min of inactivity.

      So either your orgs security policy has stipulated a time limit or the admins left it at default and/or their best guess at a suitable timeout.

  5. Doctor Syntax Silver badge

    "zero-trust architectures, which take the position that anything or anyone trying to climb onto a network can't be trusted or given access until verified"

    Unfortunately this conflicts with my position that anything pushing a text or email at me can't be trusted until verified.

  6. HappyDog
    WTF?

    Am I streaming?

    Is this new?

    Is this not what Netflix and all the other streaming services do already?

    Just asking for a friend...

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like