It's Time to Hang Up on Phone Transports for Authentication
Published Nov 10 2020 09:00 AM 229K Views
Microsoft

In my blog Your Pa$$word doesn't matter, I laid out the key password vulnerabilities, and in response to a gazillion “but other creds can be compromised, too” DMs and emails, I wrote All our creds are belong to us, where I outlined vulnerabilities in credentials other than passwords and highlighted the promise of passwordless, cryptographically protected creds like FIDO, Windows Hello, and the Authenticator App.

Today, I want to do what I can to convince you that it’s time to start your move away from the SMS and voice Multi-Factor Authentication (MFA) mechanisms. These mechanisms are based on publicly switched telephone networks (PSTN), and I believe they’re the least secure of the MFA methods available today. That gap will only widen as MFA adoption increases attackers’ interest in breaking these methods and purpose-built authenticators extend their security and usability advantages. Plan your move to passwordless strong auth now – the authenticator app provides an immediate and evolving option.

It bears repeating, however, that MFA is essential – we are discussing which MFA method to use, not whether to use MFA. Quoting an earlier blog, “Multi-factor Authentication (MFA) is the least you can do if you are at all serious about protecting your accounts. Use of anything beyond the password significantly increases the costs for attackers, which is why the rate of compromise of accounts using any type of MFA is less than 0.1% of the general population.”

The Usual Suspects


It’s worth noting that every mechanism to exploit a credential can be used on PSTN – OTP. Phish? Check. Social? Check. Account takeover? Check. Device theft? Check. Your PSTN account has all the vulnerabilities of every other authenticator and a host of other issues specific to PSTN.

Not Adaptable


Because so many devices rely on receiving PSTN messages, the format of the messages is limited – we can’t make the messages richer, or longer, or do much of anything beyond sending the OTP in a short text message or a phone call. One of the significant advantages of services is that we can adapt to user experience expectations, technical advances, and attacker behavior in real-time. Unfortunately, the SMS and voice formats aren’t adaptable, so the experiences and opportunities for innovations in usability and security are very limited.

Transmitted in the Clear


When SMS and voice protocols were developed, they were designed without encryption. From a practical usability perspective, we can’t overlay encryption onto these protocols because users would be unable to read them (there are other reasons too, like message bloat, which have prevented these from taking hold over the existing protocols). What this means is that signals can be intercepted by anyone who can get access to the switching network or within the radio range of a device. As I said in the earlier “All Your Creds” blog, “an attacker can deploy a software-defined-radio to intercept messages, or a nearby FEMTO, or use an SS7 intercept service to eavesdrop on the phone traffic.” This is a substantial and unique vulnerability in PSTN systems that is available to determined attackers.

Easy to Social Engineer


It’s worth noting that most PSTN systems are backed by online accounts and rich customer support infrastructure. Sadly, customer support agents are vulnerable to charm, coercion, bribery, or extortion. If these social engineering efforts succeed, customer support can provide access to the SMS or voice channel. While social engineering attacks impact email systems as well, the major email systems (e.g. Outlook, Gmail) have a more developed “muscle” for preventing account compromise via their support ecosystems. This leads to everything from message intercept, to call forwarding attacks, to SIM jacking.

 

Subject to Mobile Operator Performance


Unfortunately, PSTN systems are not 100% reliable, and reporting is not 100% consistent.  This is region and carrier dependent, but the path a message takes to you may influence how long it takes to get and whether you get it at all. In some cases, carriers report delivery when delivery has failed, and in others, delivery of messages can take a long enough time that users assume messages have been unable to get through. In some regions, delivery rates can be as low as 50%! Because SMS is “fire and forget,” the MFA provider has no real-time signal to indicate a problem and has to rely on statistical completion rates or helpdesk calls to detect problems. This means signal to users to offer alternatives or warn of an issue is difficult to provide.

 

Subject to Changing Regulations


Due to the increase in spam in SMS formats, regulators have required regulations on identifying codes, transmit rates, message content, permission to send, and response to messages like “STOP.” Unfortunately, however, these regulations change rapidly and are inconsistent from region to region and can (and have) resulted in major delivery outages. More outages, more user frustration.

Limited Context


In practical terms, the text or voice mediums limit how much information can be communicated to a user – SMS carries 160 characters, 70 if not using GSM, and once we get into languages which require encoding, the practical limit without message splitting is only around half that. Phishing is a serious threat vector, and we want to empower the user with as much context as possible (or, using Windows Hello or FIDO, make phishing impossible) – SMS and voice formats restrict our ability to deliver the context under which authentication is being requested.

Authentication Evolved


Ok, to recap: you’re GOING to use MFA. Which MFA? Well, for most users on their mobile devices, we believe the right answer is app-based authentication. For us, that means the Microsoft Authenticator. The Authenticator uses encrypted communication, allowing bi-directional communication on authentication status, and we’re currently working on adding even more context and control to the app to help users keep themselves safe. In just the last year, we’ve added app lock, hiding notifications from the lock screen, sign-in history in the app, and more – and this list will have grown by the time you plan your deployment, and keep growing while SMS and voice keep sitting still.

Hang up on PSTN and pick up the Microsoft Authenticator – your users will be happier and more secure because you did.

Stay safe out there,

Alex (Twitter: @alex_t_weinert)

44 Comments
Iron Contributor

Makes sense! However SSPR requires to enable another method besides the app. What should be the second one - by the book? There is not that much choice.

Brass Contributor

Great article. What are your thoughts on using email as a 2FA?

Copper Contributor

I agree on PSTN not being that reliable and secure anymore. However, solely relying on an authenticator app introduces quite a dilemma when the phone is lost or changed. Although MFA registrations may be restored in the app, OTP codes and notifications are disabled until re-registered with Azure MFA. But you can't restore these factors without another one to get there. I guess another possession factor such as a security key (e.g. FIDO) will have to get more common to completely dispense on PSTN.

Brass Contributor

Too bad that the Microsoft Authenticator app doesn't provide any context to the authentication request (no location/IP, no target application etc.). Our users will click on Approve without knowing if it was them or not. You guys have a lot of work to do.

Copper Contributor

I currently use SMS-based MFA, and understand its problems, which you've laid out well.

 

But what scares me about using the Authenticator app is that a large number of my users are, well... inattentive, to put it charitably, and would be highly likely to approve any authentication request they got without giving any further thought to whether it was legit. Too many of them seem to have a genetic predisposition to clicking things like "Yes", "Allow" without understanding (or even bothering to read) what they're clicking on.

 

At least with SMS, if a fraudulent logon attempt generates an OTP, the user can't funnel that back to bad guy, and that's why I'm sticking with SMS for now.

 

 

Copper Contributor

Do the regulations also prevent something like this:

 

sending an encrypted captcha over multiple messages, 

 

your app then uses private key to decrypt and show the captcha, and the user looks at the captcha and enters it to proceed

Copper Contributor

PSTN is used by wired phones and in most countries only does voice calls.  SMS is generally to mobile phones which doesn't use PSTN.  it uses GSM.

 

But yes, I agree with moving away from passwords/passcodes/pass phrases to more secure FIDO type mechanisms

Brass Contributor

@Alex Weinert Sounds all nice and dandy until your users replace their cell phones at the store and then realize they are locked out of business accounts.  This is why SMS is handy as a backup.

 

If you want SMS gone then you will have to change the defaults in your MFA registration.  The second default method Is always phone/SMS when the minimum methods is set to 2 for SSPR combined experience.

 

Finally, your force push of app lock was a bad idea and only steered more of our users away from Authenticator.   Was the risk of phone theft so much that you had to force it on everyone?  You can't lock a hardware token which is likely on a key ring, and just as likely to be intercepted as a phone.  Poor choice. 

Brass Contributor

@Joseph_Moran Yes, Authenticator is long overdue for adding context information like the name of the app and location of the requestor in the push event.  They should be doing this and not features like App Lock, IMO. 

 

Copper Contributor

I understand all your points, but there are some situations--that involve a LOT of people--where a telephone call is the ONLY way to verify MFA.  Specifically, there are a military, civilian, and contractors that work in Sensitive Compartmented Information Facility (SCIF) that is used to process classified information.  Cell phones are strictly forbidden.  If you're lucky, they have a containers for cell phones outside the SCIF.  But trying to verify with other than a phone call (since it's right on the desk) is nearly impossible.  DoD rules require you to lock your workstation if you leave it.  So to try to use an app is cumbersome at best, because once the the request hits the screen, you have to lock your workstation, wait for the CAC reader to finish writing to the CAC, remove your CAC (because that's also a requirement), run out of the SCIF, and hope you're in time to hit approve on the app.  If you're trying to use the pseudo-random generated code.  The time is even longer.  Because now I have to badge into the SCIF, run to my computer, put my CAC in the reader, log into the system and hope that I'm in time again.

 

Given that the phone systems and phone lines are run through a military base and likely a switch, it's much more secure than you're usual landline.

 

Again, I get the emphasis on moving away from phone and text MFA, but there ARE situations where it's not only appropriate, but necessary!

Copper Contributor

App-based authentication is great. Lots of sites have implemented it, and I see users across the spectrum eagerly picking it up.

 

But who you need to be convincing are banks and financial institutions. I can't find a single one (at least in the U.S.) who uses app-based TOTP under the MS Authenticator/Google Authenticator/Authy regime.  I know of a few that experimented with RSA tokens back in the early to mid-2000s, but in recent years, it's as if they all just quietly dropped the idea and fell back on email and SMS as 2FA.

 

I've tried finding out myself why this is. I've heard various theories -- regulatory hurdles, technical inertia, or cost. I've even asked my own bank, and got a non-answer answer.  But surely the APIs for implementing it can't be any more difficult or costly than setting up an SMS gateway?

Bronze Contributor

Thank you @Alex Weinert for your valuable weblog.

Agreed with all points, however one drawback with MFA app is in case someone steal the phone , then user would have hard time and it prevents them from login to their accounts. Especially based on my discussion with IT Professionals from all over the world, almost all countries don't have strong and reliable police to recover their phones and they end up buying new phone and reinstall everything. This is one of scenario where I usually support cloud-based backup.

Steel Contributor

@Alex Weinert We've migrated many customers to MFA during the last couple years (100,000+ users) and of course this has improved security a LOT.

 

However, as previous commenters have pointed out, we do have had incidents where user just by laziness has answered "Approve" on authentication notifications in the app and let the perpetrator in since they had the username/password. No matter how much security education effort we put in, this happens on a regular basis I'm afraid. I would think not more than 0,01% of our user base but that's enough to create huge problems.

 

What plans do you have for minimizing the risk for this? Adding more information to the push notification? Forcing the user to select a correct number out of three as you do on Personal Microsoft Accounts?

Iron Contributor

Deleted comment

Iron Contributor

This blog post is spot on and I appreciate having all the weaknesses lined up. However, the app is not the silver bullet replacement even though it is a good solution.

 

I agree with most comments about the app needing improvements to prevent users from being... users. Also the comments about a phone not always being an option is very true for our org. Our staff members often work in environments where mobile phones are strictly forbidden (meaning SMS is useless anyway). We also have the legal dilemma of requiring some staff to install an app for work on a personal device – far from everyone have a company issued phone. You will face issues on many levels when asking staff to do this.

 

As a result, I am still hoping to see a lot more investments in FIDO/hardware MFA capabilities. We are issuing OTP credit card style hardware tokens as an excellent option to the app (although expensive). However, the reliance on third party apps for programming/administration of these tokens can be made a lot smoother with better integrations in AAD. It should be equally easy to issue a hardware token as it is to issue the app.

Deleted
Not applicable
Deleted
Not applicable

@jerrydunn SMS can contain more information: last 4 digits of account number, the amount, etc, than just "approve" in any generic MFA app.

please read:

https://securitynews.sonicwall.com/xmlpost/malware-switches-users-bank-account-number-with-that-of-t...

https://www.cert.pl/en/news/single/new-vb-malware-that-changes-bank-account-number-when-copying-from...

 

 

Your single "OK, approve" might send money to a different account far far away, while SMS-based MFA allows for more details and potentially discovery of this fraud.

Copper Contributor

On the MFA Authenticator App concerns and the fact that users will blindly click "Approve" on something, they have no idea (Absolutely shocking btw) maybe we just allow admins to turn that function off. When a user requires to do MFA they open the app and acquire the code. Old school.

 

For our Front Line workers that have no email accounts and such but do log into other enterprise apps the challenges for them managing userid/passwords is a significant challenge. SMS is simplistic enough to allow that authentication with lower risk.

 

Again no silver bullet. But there are enough options that you can use for the right situation and address the right risks. As long as you can leverage the configuration of persona-based MFA this would be the best option for now I believe.

Copper Contributor

While I agree with you, Microsoft should follow their own advise. I attempted to install hardware security key to my microsoft live account, but the system does not let me remove the phone number and SMS as a possible authentication method. As a result, the account could be compromise by a SMS hack bypassing the hardware key. If Microsoft really believe SMS is dead, they should have offered an option to remove SMS form the microsoft live accounts.

Copper Contributor

Nice information...

Azure cloud and cloud migration services provider...

microsoft azure cloud services

 

 

Steel Contributor

@Alex Weinert A lot of questions and suggestions in this post, any comments if any of the features mentioned is coming? Would help a lot in our discussion with customers.

Steel Contributor

It would be great if we could set "text message" to "not allowed" but users are not forced to change to the Authenticator app right away. Or if we could deploy it in rings

 

We have 1100 users (out of 2400), mostly external guests, who use SMS as default method. We plan to switch it off - but every time we get the report. We have 100 users that configured it like that because it is the "standard".

 

Service Desk would gone down as soon as we switch the setting.

 

Copper Contributor

I agree with the idea of migrating away from the lower security solutions provided by mobile/telephone networks and it appears this thinking is well in line with NIST recommendations.  To me this leads us into one of two directions, either utilisation of biometric factors, or (more likely) towards more use of the "something you have" type (such as hardware tokens or Fiido keys).  I guess the main issue with both of these options is the cost of the physical items themselves, but currently this does seem the main direction security is going in.

Steel Contributor
Copper Contributor

I was foolish enough to add several TOTP secrets to Microsoft Authenticator. Then I discovered (shame on me to not having checked that earlier) that the only way to move those secrets to a new phone is to enable a cloud backup. No local backup possible and as far as I have researched this is not a planned feature...

Never again, and not for my users if I can prevent it.

Copper Contributor

What is the best possible way to move the users that are currently using SMS to authenticate to the MS Authenticator app?

 

My idea was to create a "How to" and have them do it themselves but know users they will not take the 3 minutes to go through the step.

 

Any suggestions?

Steel Contributor

@iveloz2185 You can nudge the people to do so.

Have a look here

Nudge users to set up Microsoft Authenticator app - Azure Active Directory | Microsoft Docs

 

It will remind them that SMS is not secure and to use the Authenticator App. Please keep in mind, that one of the most successful attack methods is MFA hammering. So also have a look at this new feature: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-authen...

Brass Contributor

But, did you know with Clerk Chat non-voip numbers you can get MFA codes directly on your teams? 

Zero hassle, simple integration & instant results.

Copper Contributor

A great article, but I note that more than 2 years after this blog post and @Red Flag 's comment that the Microsoft Azure AD Self-Service Password Reset (SSPR) still - as far as I can tell - enforces the choice of SMS and phone as REQUIRED authentication methods.   It would be good if - as with Azure AD authentication - one could configure the most secure methods as per MS guidance.

Iron Contributor

@BentleyBoy

There is an improvement – what I have noticed about two months ago.

When 1 method is required – App is good enough (Mobile Phone not required anymore) – but who does require one method only?

When 2 methods are required – besides the App there is still not much choice and Mobile Phone (=both: SMS or call - no option to reduce it to SMS only !!!) is still the best option.
The new Authentication Methods Policy blade in AAD did not change much when it comes to more granular management of SSPR methods. 

To make is short:  No chance to "move away from the SMS and voice" SSPR mechanism in 2023.

SSPR methods - as of Feb, 2023:

Screenshot 2023-02-24 125230.jpg

SSPR experience as of Feb, 2023 when APP + Mobile Phone are required:
Screenshot 2023-02-24 125810.jpg

Copper Contributor

Thank you @Red Flag .  Is the conclusion here on @Alex Weinert 's article that in this case Microsoft are not giving customers the opportunity to following their own advice/eat their own dog food/drink their own champagne  (i.e. "Hang Up on Phone Transports for Authentication") where there are two methods required, or is that an unfair assessment?

Copper Contributor

@Alex Weinert Is Azure B2C affected by this change as well?

 

Thank you

Copper Contributor

I think we're ignoring a painfully obvious risk of people losing access to their account because of the change.  Loss of access is a DoS security risk via introduced downtime.  My organization has quite a few employees who do not own smart phones, and a few more who don't have cell phones altogether.  Legally, we cannot require this.  This will cause a business loss for us in lost hours on support calls due to and as well as users losing access to their account.  Many users are begrudged to install an app on their personal smartphones, which we also legally can't require them to do.  Most businesses DO NOT pay for every single employee's phone, and therefore have no right to require its use.   If it's a convenience, they can pay for it, but if it's a requirement, we have to.

 

Furthermore Notification with only an Accept requirement is painfully insecure due to notification spam.  @michaeldehaas is right on the money here - I know of a few instances where this has occured.  Simple Accept notifications without a code are not secure, and IMHO barely qualify as MFA.  OTP via authenticator app is also secure, but also easy to lose access to, and I deal with these kind of calls all the time.  After loss of OTP devices, if organizations will work with you you're introducing a commonly accepted excuse into the social engineer's playbook.  The bigger the org, the less secure this move actually is in reality.

 

Security posture isn't something you can enforce via monolithic policy - it's something you convince the user to do.  If you install complicated locks on a door that take forever to use, the user is more likely to simply leave the door unlocked entirely.

 

The appropriate course of action is to get rid of the SMS, but not the phone call.  It's much more difficult to intercept an actual call than to sniff the air for an SMS message.  Most phone carriers use VoLTE for cell calls, and by default, all VoLTE calls are encrypted.  This would encourage users to use the app and avoid using their PSTN whenever plausible.  Sure, they can still socially engineer the phone company, or perform a SimJack, but both of those instances put liability on the phone company, not the business itself, and both are likely to trigger a response from the victim.  You can't make perfect security, so you want your design to be such that breaches of security to produce obvious effects so that it can be dealt with swiftly, before evidence is lost, or the impact of the breach gets out of hand.

Copper Contributor

I am seeing the prompt to set up Authenticator App I hate that thing. Goes back to the Phone App fiasco I failed to relinquish a permission the server cut me off then device Bluetooth and the phone %^^$$        took 2 weeks to untie that knot. was a glitch on my end of the Bluetooth the server dropping signal by design triggered by logic protocol with an objective! That would be obvious. If a 3rd party outside neutral objective analysis were performed, they would come to same conclusions I did. all this A.I legislators better start at least look toward the E.U. they a father ahead of this I think a separate regulatory agency with the Sole purpose A.I. just a tool in some respects so is a gun. 

Brass Contributor

We are noticed in Microsoft 365 Admin Center (MC650420) that Microsoft will start to prompt users to register the Authentication app. Alright, that will be a shock for many of our users, but it is understandable.

 

But it's nowhere to be found if MFA by phone (Voice/OTP) will be completely deprecated or will it still be available i.e. for backup purposes, extra way to do MFA?

Brass Contributor

You need to keep SMS as an option.

Brass Contributor

Hello,

Does this affect also the B2B/Guest users?

Steel Contributor

Regarding MC650420 it says:

 

Users can skip this prompt for a maximum of 3 times, after which registration of the app will be required by default. Note: admins can decide it they want to opt out of the “limited” 3 snooze configuration or give their end users the ability to snooze indefinitely.

However, I can't find in the documentation how to configure this snooze indefinitely option. Maybe if we put it to snooze timer to 0?

Microsoft

@Ron Ron @Jacob R To clarify: there are no plans to discontinue SMS and voice.

 

@Jonas Back This feature was probably not released to your organization yet at the time of your question, but it should be now. Please reference https://learn.microsoft.com/azure/active-directory/authentication/how-to-mfa-registration-campaign for instructions

Brass Contributor

I guess I misunderstood but our company has decided to only allow MS Authenticator app.  We have already had several employees pick the wrong app on the Apple store.  Even if you put Microsoft Authenticator, of course they put an ad as the first suggestion which looks similar to MS Auth.  Thanks

Microsoft

@Jacob R It's great to hear your organization only allows the Microsoft Authenticator app! I'm sorry to hear some of your users have difficulty finding the app in the Apple store. Consider using the registration campaign feature which offers a link to download the app: How to run a registration campaign to set up Microsoft Authenticator - Microsoft Entra | Microsoft L...

Brass Contributor

Not one email about it from the higher ups, corporate or compliance.  It was more like you need to get your locations using the authenticator and slowly fircing everyone!  they dont listen to me!

Copper Contributor

Hi, is there a possibility to disable SMS/Phone for MFA?
Thanks
rgds
Frank

Microsoft

@FrankD110 Yes this is possible through the Authentication Method Policy. After you confirmed you are migrated to the Authentication Method Policy, it's two simple clicks to disable SMS and Voice for your organization. Please let me know if you run into any issues.

Version history
Last update:
‎Nov 09 2020 10:42 PM
Updated by: