No Question That MFA Should be Used, But Is It Time to Dump SMS?

SMS and Voice MFA Methods in Microsoft’s Crosshairs

On November 10 Alex Weinert, the Director of Identity Security at Microsoft, posted It’s Time to Hang Up on Phone Transports for Authentication. The article argues that it’s time to consider dumping the SMS and voice methods for multi-factor authentication (MFA) in favor of passwordless strong authentication such as that available through the Microsoft authenticator app.

As Weinert points out, the debate is not about MFA, which is an essential part of protecting any account which supports this capability. It’s solely about using the most secure MFA method. SMS is probably the most-popular method for Azure AD accounts enabled for MFA. As noted in an earlier blog, Microsoft believes that MFA-protected accounts are 99.9% less likely to be compromised, so upgrading accounts to use MFA is clearly an important line of defense for any Office 365 tenant.

The Problem with Phone Authentication

Weinert builds his case against SMS and voice authentication around weaknesses in the phone system (both PSTN for voice and largely GSM for SMS). He notes that the text and voice messages carried by these systems to allow users to authenticate are limited and can’t be updated for better security. The messages are transmitted in the clear and don’t support encryption. They are easily attacked through social engineering, can be slowed by poor operator performance, and deliver poor context to the end user.

App-based Authentication

Inside of using SMS or voice messages, Weinert argues for app-based authentication. For Microsoft 365 tenants that means the Microsoft Authenticator app, which uses bi-directional encrypted communications. When authenticator is used, apps which need to sign in gather the account name and password and then send a request to Authenticator to complete the MFA process (Figure 1).

The process to enable authenticator for an account registers the device where approvals are given. Azure AD sends the request to the device which shows up in the Authenticator app. I use the authenticator app on an iPhone to approve sign-ins to my account (Figure 2). If the registered device is to hand (a common problem with all MFA methods), the process is quick and simple and works well, albeit with some potential issues lurking in the background.

Managing MFA Inside Office 365

Configuring user accounts to use MFA is reasonably straightforward. You can do it on an account by account basis by editing the accounts in the Microsoft 365 admin center (Figure 3), selecting the account from the list displayed in the Multi-factor authentication management page, and enabling the account.

It’s also possible to enable users with PowerShell. Today, this can be done using cmdlets in the old Microsoft Online Services module rather than the newer Azure AD module (here’s an example of how to create a report of the current MFA status of tenant users). This code snippet enables MFA for an account and makes one-way SMS the default method (the mobile phone as set in the user’s Azure AD account is used for the call).

$UPN = "[email protected]"
$MFASetup = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$MFASetup.RelyingParty = "*"
$EnableMFA = @($MFASetup)
$MFAOptions = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationMethod
$MFAOptions.IsDefault = $True
$MFAOptions.MethodType = "OneWaySMS"
Set-MsOlUser -UserPrincipalName $UPN -StrongAuthenticationRequirements $EnableMFA -StrongAuthenticationMethods $MFAOptions

If you want people to use the Authenticator app, it’s best to have them go through the setup process in the Security Info page (Figure 4) so that the link is created between their account and the device they want to use with Authenticator.

To reset MFA for a user and force them to reselect a secondary authentication method, you can run the Reset-MsolStrongAuthenticationMethodByUpn cmdlet.

Finally, in situations where you want to roll-out MFA generally, the first thing to do is to prepare the ground with user education. Afterwards, the suggested approaches for tenant-wide adoption include Security Defaults for the organization or use Conditional Access policies (with Azure AD Premium P1 licenses).

Authenticator Challenges

Although the authenticator approach is clearly a more secure authentication method than SMS, the real-world voice of administrators clearly came through in comments posted for the article. People cited the laziness of users who hit approve for every authentication request, no matter what app the request comes from. The danger then exists if an attacker has a username and password, the one-click approval on the authenticator app is an unexpected weakness.

More effort and involvement are needed for someone to look for and input the six-digit code sent by SMS to complete the MFA process. The underlying truth here is that if people are careful about security and understand what they’re doing, authenticator works very well. But like anything in life, when shortcuts are taken, security is often weakened.

Another commentator pointed out the challenge of depending on phone-based authenticator apps when working in highly secure environments where mobile phones are forbidden. And finally, we have the situation where people replace their mobile devices and suddenly find that they can’t sign in until they setup authenticator again. More friction obviously exists here than when using SMS.

Whatever You Do, Enable MFA

To go back to one of the points strongly made by Alex Weinert, the argument is not about if MFA is a good thing. It is. There’s no debate on this point. The sole question is what method to use to achieve MFA. I suspect this will be a long-running argument between those who see the value and utility of one-time codes transmitted by SMS and the greater security (unless users don’t pay attention) of the app-based approach.

SMS or app – it doesn’t matter. Just do MFA.