Published on

SMS OTPs: Bad for Security, Architecture, Engineering, and Call Centres

Authors
  • avatar
    Name
    Mark Williams
    Twitter

Overview

Unfortunately SMS OTPs -- and even email OTPs/magic links -- are still common in customer identity. Why? Most companies collect their customers' phone numbers and/or email addresses, and hence adding an OTP for MFA or step up authentication is relatively simple. Few companies want the high friction of using Google/MS Authenticator or creating their own authentication app, passkeys are still new and complex, and hardware tokens add a huge overhead/cost for both companies and customers.

The security problems of SMS OTPs are well known: The SS7 network is notoriously insecure, SIM cards can be cloned, mobile phone network retailers can be tricked into issuing new SIM cards to attackers, there is no end-to-end encryption of SMSs, mobile phones can be hacked, SMS OTPs aren't phishing resistant authentication factors, and SMS OTPs enable toll fraud attacks. Still, SMS OTPs offer better security than a simple password, and email OTPs are less secure due to the fact that an email account is easier to take over than a mobile phone.

Likewise, email OTPs aren't a good idea whereby customers can reset their password by an email magic link, which means that attackers only need to compromise an email account to reset a customer's password, then log in with their password and an email OTP.

Architecture, Engineering, and Call Centres

There are other problems with SMS OTPs, too. Architecturally, companies require a means by which phone numbers are included in a customer's profile when provisioning a customer into an IdP. The phone number must also be enabled as an authentication factor. But what if a customer changes their phone number? Then companies require a means by which a customer's phone number can be updated in the IdP, by self service (e.g., in a mobile app) or by the call centre.

Typically changing a customer's phone number requires APIs and integration with the IdP/CRM. What if some customers don't have a phone number? Now one must decide if the customer is provisioned, can fall back to an email OTP, or can simply add their mobile phone after successfully authenticating with a password... and the company's CRM is updated with the phone number. Moreover, call centres also need identity verification systems and processes to prevent attackers from updating a customer's phone number, then logging in as the customer.

Many IdPs -- e.g., Okta, Auth0 -- will require that the phone number is in the E.164 format. Your CRM should also include data integrity rules around the length and composition of the phone number. Likewise, some IdPs will even reject a phone number being added to a customer's profile is the phone number is not in an allocated range, or if the phone number has been used for fraudulent activities.

Should companies verify a customer's phone number? Many companies do not, because email addresses tend to be verified for communications and account/password reset flows, and verifying a phone number in addition is seen as too much friction. Without verifying customers' phone numbers, one can never be sure that the phone number entered is correct.

What about cost? Each SMS OTP will incur a cost. Multiplied by the number of unique logins per year, this can end up costing companies tens or hundreds of thousands of dollars.

What about enabling your SMS provider for overseas phone numbers? Your SMS provider may request you to raise a request for each overseas country to meet the country's regulatory requirements. Let's not even discuss how SMSs are a best effort service.

SMS OTP Implementations

Any SMS OTP implementation also needs to deal with basic security controls:

  • How many unsuccessful OTP attempts are allowed?
  • What does one do if too many attempts are tried? Lock out the authentication factor? Lock the account?
  • Any custom implementation without an IdP must ensure that the password factor, then SMS OTP are sequenced correctly. That is, attackers cannot bypass the password factor and go straight to an SMS OTP. Engineering must deisgn a solution such that the API receiving the entered OTP is on the public Internet but cannot be used without successfully authenticating with a password.