Developing applications around SMS has become very popular, with several companies offering simple to use APIs and attractive pricing to send and receive SMS. One security-related application of these SMS APIs (for the right or wrong reasons) has been simple two-factor authentication. This time, I don't want to talk so much about the security reasons not to use SMS to authenticate to critical systems, but some of the technical changes that are happening with SMS in the US and Canada.

Carriers in the US are usually not allowed to interfere with message delivery. The issue is similar to the larger "net-neutrality" question. Services considered telecommunication services must not be restricted or filtered, while information services can be restricted. Carriers argued that to curb spam and abuse of text messaging services, they need to be able to apply restrictions.

Late last year, the FCC did issue a ruling allowing carriers to restrict and filter SMS/MMS messages [1].

Starting this spring, some carriers in the US rolled out filters to restrict messages sent by applications. This "A2P" (Application to Person) messages can no longer be sent from regular long-distance numbers. Many small applications use standard long-distance numbers to send messages because they are cheap (typically about $1/month). The alternative is either toll-free numbers or shortcodes. Shortcodes are 5-6 digit long numbers specifically used for SMS, and they can not be used for standard voice calls. They can be very expensive (approx. $1,000/month),

 If your application uses SMS to, for example, notify you of system outages or send you a 2FA code, your messages may not be received if you are using a standard long-distance number to send the messages from. I found that there is often no error message in this case. The easiest (cheapest) solution right now appears to be to move to a toll-free number. They are not very expensive ($2-5/month) if you don't care about the exact number and are willing to accept one of the less known toll-free area codes like 833. For shortcodes, some services offer "shared codes" where your application uses the same shortcode as other applications, but this can be more difficult to use in particular if you are expecting replies.

Of course, there are a few other methods to send messages:

• Phone companies usually offer email to SMS gateways. These appear to be unaffected. But you will need to know which carrier a particular number is associated with.
• You could use other messaging services (iMessage, Slack, Telegram...) that have some form of API. But again, you will need to support different services and different APIs making development more difficult, or you may even need to develop a dedicated mobile application.
• There are some newer messaging standards like RCS. Just last month, the big US carrier finalized an interoperability standard for RCS, and it is still a bit too early to use it. Ultimately RCS is supposed to replace SMS/MMS. It allows for features like group messaging, and rich character sets that users have become accustomed to from other messaging services. The FCC ruling does not cover RCS at this point.

[1] https://docs.fcc.gov/public/attachments/FCC-18-178A1.pdf

---
Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
Twitter|