Originally published at: Not Receiving SMS Text Message 2FA Codes? Call Your Carrier - TidBITS
After failing to receive SMS text messages from five financial services websites that use them for two-factor authentication codes, Adam Engst resolved his problem with a quick call to T-Mobile to remove an automatically created system-level block on those numbers.
4 Likes
Thank you for those word of caution, @ace.
Just one question for you to answer in the future: will you notice an increase in the amount of SMS spam you receive on that number?
1 Like
I have two problems with SMS 2FA.
- First, believe it or not, not everyone has a cellphone.
- Second, if you’re in an area with poor cellphone coverage, it might be impossible to receive the SMS, even though you have wired Internet.
2 Likes
Your first point is a problem with 2FA in general, not just SMS 2FA. Only a relative handful of people use dedicated 2FA hardware, and those are generally among the most tech-savvy people anyway (and thus are almost guaranteed to have cellphones). The rest of us use SMS or 2FA apps. So not having a cellphone at all pretty much locks you out of using 2FA altogether. Therefore, not a big concern regarding SMS 2FA specifically.
The second problem can be resolved by using a WiFi access point with a carrier’s cell-service-over-WiFi feature (such as Verizon’s WiFi Calling). This routes cell-network signals through a connected WiFi network if a cell signal is unavailable (or preferentially, if you have it set that way). This isn’t for data, which is Internet anyway, but for voice and text, which by default are not sent over the Internet. I wouldn’t recommend using it to receive an SMS 2FA code via a public hotspot, but with a trusted home network, it’s a reasonably secure option.
The fundamental problem with SMS 2FA, as Adam has pointed out before, is that phone numbers are relatively easy to steal these days. If someone clones your SIM, they’ve got full access to anything you subsequently receive over SMS. But it doesn’t grant them access to your apps, keeping things like Google Authenticator safe from this particular exploit. So security, not lack of access, is SMS 2FA’s Achilles’ heel.
2 Likes
I believe this is really primarily an American thing. None of the European countries I spent time in would allow you to order a new SIM without showing up with some form of government issued photo ID or further verification. This thing that some twerp can call up a cell provider, pass on a ZIP code as “authentication” and then have a SIM shipped to some shady PO Box seems to be a distinctly American issue. What I’m getting at is this is a choice we seem to have made somewhere along the way. Others appear to have made better choices. Perhaps we need to revisit this issue and reconsider if sacrificing security for convenience is really the right call when we rely on this conduit for such sensitive matters such as authentication. That said, I’m not trying to argue for SMS 2FA. I just think it doesn’t have to be as crummy as we have made here in the States.
3 Likes
Some service providers (e.g. Google) give you the option to receive an SMS code via a voice call. Of course, if you don’t have a mobile phone, you’ll need to be near your land line in order to receive it.
I’m actually surprised that we don’t see desktop apps for generating TOTP authentication codes. The algorithms are industry-standard (RFC 6238), and there are open source libraries that implement them. But it seems to be rather hard to find a desktop app to present it in a friendly way, the way many apps do on mobile platforms.
Regarding 2FA, there are other alternatives. But they’re not as widely used on the Internet:
-
A TOTP authentication code using a proprietary algorithm. Apple’s iCloud authentication is one. (Note that the codes presented on a phone, iPad or Mac are locally generated, not received from the server. You can also manually request codes.)
-
Voice call. Google supports this, as do some banks. You still need to be near the phone that will ring when the registered phone number is called, but you don’t need to be able to receive text messages.
-
Paper codes. Google lets you generate 10 “emergency” single-use OTP codes that you can print and keep with you, for when you have no other means available. But I haven’t seen anybody else support this. Of course, if you use this as your primary mechanism, then you must make sure to generate/print more as you use them up.
All of the major US carriers have similar policies, but unfortunately there are many recorded incidents where customer service personnel were convinced to violate policy in response to a suitably convincing sob story (or sometimes outright bribery). Even when the owner of the account enabled all of the extra optional security features designed to prevent this.
Customer service staff have lost their jobs over this, but it doesn’t do you a whole lot of good if you’re the person who got victimized.
1 Like
Authy is available as a desktop app, it will sync alongside phone/tablet/etc versions.
f
1 Like
Good to know about Authy.
I forgot to mention an additional alternative for receiving SMS when you have poor cell connectivity: iMessage. If you have an iPhone and a Mac, you can connect your Mac’s Messages app to your iPhone through your Apple ID, and thereby receive your SMS messages on your Mac via iMessage regardless of cell connectivity, as long as you have an Internet connection.
I’ve been doing this since my first iPhone, and it makes using 2FA codes on my Mac so much easier (just copy and paste). It also means that I don’t have to pick up my phone every time I get a text while I’m working.
I don’t see how that can work if you don’t have cell coverage at all. An SMS is sent over the cellular network. It only gets displayed alongside iMessages in the Messages app, but it still remains an SMS. If cell coverage goes away, there is no SMS traffic. Your Mac can use an attached iPhone to receive and send SMS, but when doing so it still relies on the iPhone being able to connect to the cellular network. If you have cell service over wifi, wifi can effectively “extend” cell coverage even outside of the provider’s usual coverage area, but ultimately that message will always come in as an SMS over the cellular carrier’s network. If that goes away, there is no more SMS traffic.
For this to serve as a truly independent alternative, you’d have to be able to choose to receive 2FA codes as iMessage instead of SMS. That way all you’d need is a data connection, possibly through wifi or Ethernet, independent of cell coverage. I’m not aware any company I do business with offers to send iMessage instead of SMS.
And BTW, Authenticator exists as a desktop app on the Mac. It’s on the MAS. It can sync over iCloud with your iPhone etc. (if you get the paid version that is).
3 Likes
I’d be surprised given how few websites/numbers were affected by the block, but I’ll certainly keep an eye out. I get almost no spam now, if you don’t count all the political candidates.
I have very little experience in Europe, but it does seem to be an issue there, if this article is an indication.
You may be right about needing the cell network to get the SMS via iMessage in the first place. I’ve never tested it without my cell phone being nearby and on.
I will mention, though, that I have occasionally flaky cell service where I am, and I have occasionally received a notification for an SMS message on my Mac, but the phone doesn’t show it until after a distinct delay. (Not the notification, but the message itself not showing right away on the phone. Sometimes I’ll see the notification on my Mac and choose to view the message on my phone.) From that, I guess I assumed that the phone didn’t need to receive the message first, but those occurrences may have been due to a device issue (like most people, I don’t reboot my phone nearly as often as I should)—the phone got and relayed the message, but the iOS Messages app didn’t display it.
Interesting. And this SMS (green-bubble message)?
I don’t know what’s going on, but here’s my (hopefully educated) guess.
SMS is a very low-bandwidth protocol. In its simplest form (just short bits of text with no attachments), it is just some data that piggybacks on the signaling protocols used to create virtual circuits (like those used to connect voice calls).
I could easily see a situation where the network quality is too poor to establish a connection (no voice calls, no data, zero bars), but there is enough for SMS to slip through. Possibly in bits and pieces as the network attempts to retry delivery over time.
In a situation like this, the phone might see the start of a message (including its caller ID) and assume that more is to come, and therefore generate the notification at that point. Then when the rest of the data eventually arrives, it can present the rest.
But this is just a theory. I don’t know nearly enough about the details of mobile phone networks to be sure about this.
Received messages don’t show green or blue, only sent messages.
But I know they’re SMS. The ones this usually happens with are automated notifications from businesses or medical providers—those systems are never going to be iMessage unless Apple opens the protocol outside of Apple devices. It’s usually the lengthy messages with lots of unnecessary boilerplate text, too. That may have something to do with it.
Thanks Adam, this is a helpful writeup.
When doing some Bitcoin experiments in 2018 I ran into a similar 2FA surprise. At that time many of the sites one used for mining wanted or demanded 2FA and encouraged use of Google Authenticator. You muddled through and soon had multiple accounts with 2FA on various sites but now dependent on password + Google Authenticator. When I got a new iPhone and migrated via iTunes backup and restore Google Authenticator lost its configuration, broke and I hadn’t written down the original seed on paper needed to get it working again with all my Bitcoin related 2FA sites. Some of the sites had a 2FA lost equivalent of password recovery and others had to be abandoned.
As you correctly note some institutions embrace 2FA and its great “when it works” without an appreciation for the fragility it introduces. They pass some regulators “we are more secure” checkbox by adding 2FA without an appreciation of failure modes and process to deal with them.
That’s really annoying. The lesson here (for those of us who might need to do this in the future) is to make sure everything migrates correctly before wiping the old phone. And try a second time if it doesn’t work the first time.
FWIW, when I migrated from an iPhone 6 to a 13, using direct device-to-device migration, my Authenticator codes all migrated OK.
It’s also worth noting that the current version of Authenticator has a feature that will let you export some or all of your keys to a QR code, which can be used to import them into another device. But I don’t think this feature was in the app in 2018.
(And, FWIW, after writing this, I decided to generate that QR code and print a copy to keep in my file cabinet, for emergency recovery.)
That’s indeed fine advice if you’re just migrating from an older iPhone to newer. But folks who are moving to a newer iPhone after they perhaps lost theirs or it got destroyed need to be able to rely on migration from backup working out 100% irrespective of the state of the old iPhone.
It would be nice to know Apple and app manufacturers keep that in mind when they design their backup/sync tools and strategies. In my personal experience, the last migration in 2020 to a 12 mini from an SE worked well, but Google Authenticator (that my employer forces upon us) was one of the few holdouts that had to be set up from scratch despite iCloud drive in principle being available to the app for backing up. On my main work Mac I use Authenticator App for this Google authentication stuff and that app (in its paid version) actually backs up to iCloud drive so that you can always recover, but also such that you can have it sync to all your other Macs and iDevices. Haven’t had to rely on that so far (and hence no personal experience actually testing that feature), but sure sounds very handy to me.
1 Like
And this is why you use something like Authy that is distributed across various devices…
That was my driver for moving years ago because the Google implantation didn’t support multi-device/transfer etc. in a sane manner.
If your company insists you use a broken authenticator I am not sure why you get to blame Apple for that, just use a sane one that works for everywhere else. However as an open standard it is quite hard to insist that you must use a particular implementation other than by corporate policy and discipline.
I hadn’t thought about it but for some 2FA actions on my Mac the Mac receives the code and prompts me to use it to fill in the field. This happens with Apple services but also some others.
This is convenient as I don’t have to go searching for my phone but, on the other hand, it seems to defeat the purpose of 2FA since the device that is requesting the 2FA is the same as the device providing the code.
In any case, I agree that 2FA via SMS is lazy security on the part of service providers.
One of my banks uses an iOS security app called VIP Access that seems more secure. It is a little taxing for us, however, as it gives you just 30 seconds to read and enter the code. Also I found out that it is locked to a particular phone and to change phones it needs to be deauthorised on the old phone (if available!) and authorised on the new one.
2FA (at least these days) doesn’t hinge on requiring two separate devices. It requires something you know (user/password) plus something you have (device). That way if somebody gets one, they still can’t get in without also obtaining the other.
I very seldom use text messages at all. I usually do log-ins from my iMac so if I have the option, I use email OR a phone call. In addition even though my home phone is labeled HOME and not CELL, some sites want to send texts to my home phone!
Oh another bugaboo (primarily from Apple) is when I go to log in from Safari, they want to send me a code to verify a new browser. After entering the code I’m asked if I want them to trust my browser, and I say “yes”. So the next time I log in from the same iMac running the same MacOS version and using the same Safari version, I often get the same demand to verify “a new browser”!
1 Like