What To Do if You Must Use SMS
There are many known risks in life that you simply can’t get rid of altogether.
Despite everything we know about the risk of SIM hijacking as a vector of compromise, there’s no way that we can reasonably tell organizations to stop using SMS authentication. For one thing, not everyone owns a smartphone; you can’t force third parties and users outside of your control to switch to the device you prefer, or even agree to install a specialized app. SMS is the greatest common denominator, both in terms of global reach, user familiarity and openness; it’s the fallback when you need an out-of-band confirmation and you can’t rely on email, hard tokens or U2F keys.
To mitigate this risk, you can try user education, out-of-band notification, or add more authentication factors.
User Education
User education is where you train the user to distinguish between legitimate actions and suspicious ones in the authentication process. For example, there are efforts to standardize the format of a one-time SMS code so that apps and people alike can detect when it’s not coming from the original site, but rather from an attacker. In essence, you are relying on the user to perform some or all of the detection: if an auto-fill mechanism isn’t being triggered to enter the SMS code into the authentication field, the user is supposed to realize that this might indicate a phishing attack.
This mitigation has the advantage of being technologically feasible, but it has the disadvantage of depending on your entire population of fallible, unevenly skilled, carbon-based life forms to pay attention and notice something subtle every time it happens. Let me know how that works out for you.
Out-of-Band (OOB) Notification
When you don’t fully trust one communication channel, you supplement it or bypass it with another one. In this case, if you are concerned that one prevention method has failed (that is, you think an attacker has taken over control of a user’s registered phone number in order to receive phone calls or SMS messages), you set up an alerting function that uses something else that ought to be remaining in the user’s possession. A notification by email, a direct message through another application, or even an alert sent to a third party (such as an administrator) are all options.
As the old saying goes, “What you cannot prevent, you must detect.” The detection and subsequent notification should all be done by separate systems that don’t rely on what the attacker has already obtained and controls.
For example, when a Duo user enrolls a new device, you can use the auth log data and your alerting tools to send a notification to the user, to the Duo administrator, or both. This can help alert you to an unauthorized enrollment by an attacker.
Another example: if a user calls the help desk on a voice line and claims to have forgotten their password, the help desk can send a Duo push notification to the user’s mobile device of record to confirm that it really is the same person. The user must respond to the push to prove that they do have possession of that instance of the app. A chat bot can be used to send an out-of-band notification through a corporate messaging app: “Did you really mean to do this?” The key is to compensate for the risk that an attacker might have possession of the victim’s phone number and therefore be able to see and respond to SMS messages.
Adding More Authentication Factors
You may have to rely on SMS in some cases, but that doesn’t mean it needs to be the only factor being used. Consider that some factors can be stolen silently, such as a username, password, or the control over a phone number. Others can’t be stolen without someone noticing.
If a U2F key goes missing that is attached to the user’s keyring along with car and house keys, it won’t be long before that user notices the theft. A smart card, a biometric, or access to an endpoint device such as a laptop that requires specialized hardware components to work, all mean that on top of swapping a victim’s phone SIM, the criminal must also steal or duplicate a variety of devices, readers, and software. With every layer that you add, the attacker’s job becomes more difficult and prone to detection.
If you have less trust in SMS as a standalone authentication factor, then you can implement a policy that prevents it from being used by itself. If SMS is used on an exception basis, you might also require the geolocation to be in a predetermined range. Or if it’s used regularly, you could require the access to be only from a device that is registered as trusted and belonging to that user.
An attacker might steal the user’s phone number without the physical phone going missing, but if the user can only access resources through their registered laptop, then the attacker would have to steal that too.
The trick is to use layers, combinations and constraints that conform to what the user normally does anyway; this should keep that user from encountering the friction that you want the attacker to run into. And, if the user needs an exception made (for example, their laptop isn’t working or their dog swallowed the hard token), plan for an alternative authentication flow that makes use of factors that are hard to steal silently or to impersonate.
SMS isn’t as bulletproof as some may have thought in the past, but that doesn’t mean it doesn’t still have its uses. It’ll be with us for a long time. If you craft your authentication process while keeping in mind its strengths and weaknesses, you can still keep it as a part of your portfolio.
Try Duo For Free
With our free 30-day trial and see how easy it is to get started with Duo and secure your workforce, from anywhere and on any device.