The last couple of years, Microsoft has been pushing the usage of Multi Factor Authentication for logins to their Cloud Services. MFA, which requires that users authenticate with at least two factors, can reduce the risk of identity compromise by as much as 99.9 percent over passwords alone.
Now that more and more companies are implementing MFA, having the user account and password of a user by using phishing techniques is not enough anymore. But where security evolves, attacker evolve as well.
One of the ways an attacker can circumvent MFA is by using a technique called SIM swapping, and more and more news articles surface where SIM swapping is being used to get access to an account.
Someone who wants to initiate SIM swapping will gather all kinds of information about the person which is targeted. That information is then used to contact the victims mobile phone provider asking to port the telephone number to another SIM card. From that point forward any phone call but also any SMS will be sent to the person having possession of the SIM card.
And with all the data breaches which happen today, attackers have enough personal information available to convince the phone company that the caller is also the owner of the phone number, or employees of the phone companies are bribed to perform the SIM swap. On a personal note, I often see that SMS messages are displayed on the locked screen of the user, which could potentially mean that if the phone gets stolen, it’s also possible to read the code from the locked screen.
Once an attacker has control over the phone number and knows the username and password of the user, it can login on behalf of the compromised user and do all kinds of bad stuff.
Within Microsoft environments, having the option to use SMS or phone call is an option which is standard enabled. And while having MFA configured is way better than not having any multi factor authentication, evolving with the methods attackers use is a must. Therefore we must get rid of SMS sign in or Phone verification and move towards other MFA methods which are more safe.
As you can see, we ultimately want to move towards Passwordless, I already wrote about this in an earlier article which can be found here: Have you already started your journey towards Passwordless authentication on your Modern Workplace?
Within Microsoft environments that safe way is by using the Microsoft Authenticator app, or by using a Security key.
In July this year Microsoft announced the public preview of “Authentication Methods to nudge to download Microsoft Authenticator“. And with this option available, we now have the option to push our users towards using the Authenticator app by friendly asking them to register the app if they use SMS or Phone call as their primary multi factor authentication method.
If you want to know which authentication methods have been configured for your users you can use the “User registration details” report, which can be found under the monitoring section of the Authentication Methods policy. The report displays your users and shows the registered methods.
So what we are targeting here, are users which have Mobile Phone configured, but not the Microsoft Authenticator App. These users will be nudged using this new functionality. I will show later in this article what the end user experience looks like.
So let’s continue with how to configure this functionality.
How to configure the Nudging functionality
Before you can configure this functionality I advise you to check the necessary prerequisites, which are:
- Only Azure MFA is supported, so if you still have an on-premises MFA this will not work
- Users who have already set up Microsoft Authenticator will not be nudged, even though their primary method is SMS
- Microsoft Authenticator must have been enabled in the MFA registration policy and Authentication methods policy
The Authenticator settings can be verified by visiting the Azure Active Directory admin center and select Security -> Authentication Methods. For the Authentication methods either Any or Push needs to be configured, if Passwordless is specified, the Nudging will not be applicable.
The MFA registration policy is defined on the Multi -factor authentication page, which can be verified by visiting the Azure Active Directory admin center and select Security -> MFA -> Configure | Configure cloud-based MFA settings.
Enabling Nudging via the Graph API
Nudging can be enabled directly in the Graph API, chances are that Microsoft is going to incorporate these settings in the Portal GUI later on, but for now we can use the Graph Explorer to make the necessary changes.
The Microsoft documentation provides really good guidance on how to do this, and even provides several .JSON files which you can load (after modification) into the Graph Explorer to enable the functionality. Below is an example for how I configured this in our tenant, but if you want to implement this more granularly you have the option to scope to Groups. You can also specify the snooze duration, since the end user has the option to snooze the notification for an x amount of days if the value is more than 0 (in days)
Be aware to thoroughly read the documentation, fully understand what you are doing before making any modification. Compare using the Graph Explorer, with using the Registry Editor within Windows. You can make advanced settings, but you can easily screw things up as well.
The next slideshow shows the end user experience for a user which doesn’t have the Authenticator app configured as an MFA method.
So, once all your users have the Microsoft Authenticator app configured (we can use the report mentioned earlier for that), we can actually start phasing out the Mobile Phone text and call options as an available and accepted method. We can do this by modifying the MFA registration policy.
What will be the impact if we remove these methods?
If we remove the authentication methods in the MFA registration policy, this will impact your users, below are some answers to the questions I could think of.
What if user account which still only has SMS configured?
Once removed, and user only has Phone registered, the user only has the option to register one of the other available authentication methods before the login is complete and the user can access the resource.
Can the user still see the registered phone as a sign-in method?
Once removed, not see-able for the end user anymore while the administrator can still see it as a registered method.
What about the default sign-in method?
If user had Phone (text/call) configured as default sign-in method before the MFA registration policy change, the next time the user signs in, they will be asked for the configured Microsoft Authenticator app method, which will be set as default as well.
If you have configured MFA within your organization, and that is working fine a next possible step would be to further improve your security by removing the Phone options from the authentication methods available. And while ultimately you may want to move towards Passwordless, there are some cases where this isn’t possible yet.
You can also use Phone as a method when doing a password reset, you might want to consider removing that option as well, making the Authenticator app, Email and Security questions the available options left to use when Self Service Password Reset (SSPR) is being used. See the following article for more information about SSPR: Enabling Self Service Password Reset (SSPR) for your Modern Workplace users
There is also still this concept of SMS-based authentication. SMS-based authentication is used in specific scenario’s and allows users to sign in without providing, or even knowing, their user name and password. They use their phone number as their username and will be sent an SMS which serves as a temporary password. Microsoft makes this method available to login to Teams and is specifically created for so called “Frontline Workers”. It will be interesting to see, if Microsoft comes up with a safer solution for this specific scenario.