Modern online life is surprisingly difficult to navigate without a cell phone number for MFA.
It’s generally expected that you have a cell phone, accessible at all times, which can receive SMS text message MFA codes.
Companies are getting better about this – most now support TOTP (Google Authenticator, etc) or other multifactor types. However, there are several, most egregiously banks, which expect SMS-based MFA to work.
Needless to say, there are currently no cell phone towers, from any carrier, at US stations in Antarctica.
It’s worthwhile to convert as many systems as possible to use non-SMS MFA (such as TOTP, security key, etc). This is good general security practice, Antarctica or not.
The official guidance on the matter for Antarctic deployments is “disable SMS MFA before you deploy”. However, there’s always going to be a few services that require a phone number and which don’t have an easy way to disable MFA.
So – how does this play out in practice, and what can we do to maintain uninterrupted access to things that expect phone-based MFA to work?
Once again, standard disclaimer applies. I may work in the IT field, but this is absolutely not an official IT guide. This is not reviewed or endorsed by USAP, NSF, ASC, or any other entity. I’m posting to share my own research on the matter, for the benefit of other people who may have the same question.
I wrote this entirely using my own resources, on my own time, and if you read closely you’ll notice there is nothing USAP-specific here. This guide applies to any circumstance in which you need to receive MFA and you aren’t able to interactively have your phone with you and online.
Needless to say, please do not come to a USAP helpdesk and ask about this guide.
Table of contents
Failed Attempts
Here are a few strategies that sound good in theory, but which do not work for one reason or another.
Attempt #1: “Verizon Messages Plus” (thwarted by exclusions per unwritten Verizon policy)
Since your phone will be completely offline the entirety of the deployment, a reasonable first thought is to take advantage of a carrier feature, such as Verizon Messages Plus, which syncs text messages across devices.
At a high level: Instead of messages being delivered directly via oldschool SMS cellular network protocols directly to your device, messages are instead captured upstream within Verizon, and then they are synced to however many devices you have logged into your Messages Plus account. This includes laptops, which can get online in Antarctica.
This decouples your messages from the physical device itself, and it should allow you to receive messages on other devices. The syncing actually takes place using IMAP (tcp port 993), so this works just fine from Antarctica.
Unfortunately, Verizon’s implementation of this feature has an important policy carve-out, which renders it useless for MFA SMS confirmation messages. Messages Plus works with almost all messages, including person-to-person SMS, many shortcodes from businesses, etc. However, it consistently fails to work with multi-factor auth codes, with laser precision. All other text messages sync fine, but MFA SMS messages simply do not work.
Instead of the MFA SMS message syncing to all logged-in devices, it will instead be delivered only to the primary device, which is your phone, which is, unfortunately, not online in Antarctica. It’s so precise that it must be a policy decision on Verizon’s part, perhaps to appease nervous banks who don’t like anything other than pure “mobile” numbers.
This behavior isn’t explicitly documented anywhere, but there are posts on Verizon’s forums which allude to the problem, and I personally confirmed this behavior in the US before I deployed.
It’s a shame! We’re 99% of the way there, we have text messages being intercepted upstream, decoupled from the device, and being synced to authorized, online devices in Antarctica. Unfortunately though, with Verizon’s decision to bypass this feature for SMS MFA, it’s useless for our purposes.
Attempt #2: Port to Google Voice (thwarted by bank policies)
Google Voice is a popular option which provides a web-based interface for SMS text messages.
It seems straightforward – port your phone number to Google Voice, and you’ll keep your number and gain the ability to send/receive text messages from the Google Voice website, which you can access in Antarctica.
Many Antarctica folks do this! It works… alright. This is a solution which works for maybe 75% of SMS MFA sites out there, and it fails silently for the remaining 25%. The failures have nothing to do with being in Antarctica or not. This is just a policy limitation of how Google Voice numbers work, and how they are perceived by companies that use SMS MFA.
The issue stems from the fact that banks, because of Reasons, are very keenly interested to know if a given phone number is actually a mobile number, or if it’s a landline or some type of virtualized, VoIP, or other non-mobile number. As it turns out, it’s easy for companies to determine this, in realtime, using APIs provided by commercial providers.
So – if a bank sees your phone number, does a lookup using a commercially-available service, and decides that it is a “voip” number, then it may refuse to use it for SMS MFA. Foiled again!
For example, here’s a Reddit thread where Google Voice recently stopped working as an SMS multifactor authentication target for Chase Bank customers.
As an aside, Twilio is one such company that you can use to query for phone number information, using the Lookup API.
For example, here’s a Real, Genuine mobile number. This number has no issues receiving SMS MFA, but alas, it is tied to
a physical mobile phone, which won’t be able to get online in Antarctica at all. Note "type": "mobile" in the
response:
[
{
"addOns": null,
"callerName": null,
"carrier": {
"mobile_country_code": "311",
"mobile_network_code": "489",
"name": "Verizon Wireless",
"type": "mobile",
"error_code": null
},
"countryCode": "US",
"nationalFormat": "(xxx) xxx-xxxx",
"phoneNumber": "+1xxxxxxxxxx",
"url": "https://lookups.twilio.com/v1/PhoneNumbers/+1xxxxxxxxxx?Type=carrier"
}
]
And here’s a Google Voice number. Note "type": "voip" in the response 😢:
[
{
"addOns": null,
"callerName": null,
"carrier": {
"mobile_country_code": "311",
"mobile_network_code": "910",
"name": "Google (Grand Central) - SVR",
"type": "voip",
"error_code": null
},
"countryCode": "US",
"nationalFormat": "(xxx) xxx-xxxx",
"phoneNumber": "+1xxxxxxxxxx",
"url": "https://lookups.twilio.com/v1/PhoneNumbers/+1xxxxxxxxxx?Type=carrier"
}
]
Compromise Solutions
If you’ve accepted you won’t get your text messages reliably in Antarctica, and you’re OK with a partial / compromise solution, there are a few options that might help.
Compromise Solution #1: “Wifi Calling”
A reasonable thought here is to take advantage of what cell phone companies call “Wifi Calling”, or equivalent.
Basically, this means that, instead of connecting to a Verizon (etc) tower/cell and registering onto their network that way, you can connect your phone to some other Internet connection, typically via wifi. Your phone will tunnel through that Internet connection and register with your carrier. Texting and calling should work.
This is a workaround for getting texts and calls in places that don’t have cell coverage, typically for use during temporary stays in rural areas that have terrestrial broadband but no mobile coverage.
Your phone is online, just as if you were connected to a tower, but it’s connected through a different Internet connection.
At McMurdo, phones have access to a wifi network only for wifi calling and texting, not for general Internet access. It’s just a prototype at this time. It doesn’t work in all cases or in all areas, and for one reason or another it doesn’t work for some people, even if they’ve followed all the steps for enabling wifi calling.
One issue is that the protocol for wifi calling is notoriously opaque. Carriers frequently change the underlying infrastructure and protocol details.
Also, the protocol assumes terrestrial broadband with reasonable latency and bandwidth. At McMurdo, as of this writing, latency to terrestrial locations is in excess of 700 milliseconds. Usable bandwidth for any given end user can vary widely, down to a few dozen kilobits per second.
The protocol also doesn’t expose any useful diagnostic info to the end user in order to troubleshoot. You just have to cross your fingers that the magic “wifi calling” icon lights up.
Another issue is that wifi calling requires you to first register using a cellular connection, and every carrier’s implementation is subtly different. This means that if you didn’t register before you deploy to McMurdo, you won’t be able to register once you’re here.
And worse, if your registration ever lapses for any reason, you can’t get it back. It’s a risky proposition to rely on something so fragile for the entirety of your deployment.
Folks have lost their entire upcoming summer’s potential for wifi texting, because they inadvertently toggled the feature off during debugging.
It is a game-changer when it works, but I’ve found that it can’t be relied upon at this time.
Compromise Solution #2: Voice MFA
This solution is already annoying, because now we have to touch individual services and confirm/adjust their settings.
If a service absolutely, truly insists on using a phone-based MFA, check if they support voice-based MFA via the phone number instead of SMS-based MFA. It is much easier to redirect voice calls than it is to redirect SMS text messages.
Many banks support this. Apple ID and Google also support this.
Your cell phone carrier likely has a voice forwarding option. Verizon’s instructions for doing so, on a consumer plan, are here.
When you forward your cell phone number using your carrier’s administrative web portal, all incoming calls will go to the specified forwarding target. Incoming SMS will not, however. The forwarding is done upstream inside the carrier’s network, so it does not depend on whether you phone is physically turned on and connected or not. This is good, because remember, your phone has zero Internet connectivity whatsoever for your entire deployment.
Progress! If services support voice-based MFA, and you can forward your registered phone number to a number you can access, even indirectly, then you can meet the MFA challenge without having to change your phone number in each service.
For example, if you need to meet an MFA challenge, you can temporarily forward your cell phone number to a friend stateside, have them answer the voice call, and have them email or chat you the code. Or you can forward your cell phone number to a phone number you’ve rented from a service like Voip.ms that is attached to a voicemail box. Some MFA autodialers will leave the code as a voicemail; others will detect that it’s voicemail and will not leave the code.
Direct inward dialing to US Antarctic stations isn’t generally available, so you probably can’t configure your cell phone number to forward to a number you can directly answer on-station. (I’m aware of some exceptions to this.)
Note that since you have to touch every service that uses phone number MFA anyway, you could just change the MFA number to a stateside friend’s phone number, but this means you have to remember to change them all back when you redeploy at the end of your contract. Might as well leave services pointing to your cell phone number, and then just forward your cell phone number to an appropriate target as needed.
Compromise Solution #3: Give Up!
If you’ve made it this far, and if you’ve seen the hurdles we’ve jumped through so far, you might be inclined to just ignore this problem entirely.
If you try to get into an account, and you need SMS MFA… then you just wait! You’ll redeploy back to civilization in a few months anyway, how important can it be to get it done right now?
If this is you, congratulations! You have a healthier relationship with your digital life than I do.
Thousands upon thousands of people have deployed to US Antarctic stations over the past several decades, and for the most part they’ve done just fine without access to SMS-based MFA.
Actual Solutions
Alright, fine, I’m addicted to online banking (??) and I need to be able to complete SMS MFA challenges on-demand, at any hour of the day, at whatever cost, from 8,482 miles away.
Actual Solution #1: Fool Your Bank into Using a Virtual Number
Our problem with Google Voice is that it’s not a “real” mobile number, and banks know it. So, how do we get a “real” mobile number that still has features (like a web portal or text-to-email) that we need to receive SMS MFA codes?
Unfortunately this is a game of cat-and-mouse. We are asking here for something that can sneak past verification, i.e. a VoIP number that banks think is actually a mobile number. This is inherently deceptive, so API providers and mobile carriers have an incentive to stay on top of any new entrants that pop up into the market to provide such a “feature”.
Banks consider the proliferation of cheap, geography-independent voip numbers to be a security concern, so they use technical countermeasures to identify and prevent these numbers from being used as MFA factors.
Whether or not we philosophically agree with banks drawing such a distinction, the fact is that one does exist, so anything we find that works today may not work tomorrow, if verification systems are updated.
I won’t list providers that currently can sneak past verification, because 1.) I can’t vouch for their safety or security, and 2.) they may not be around next week. Remember – we are talking about banking MFA codes here, so some amount of diligence makes sense. I’d hate for someone to read this guide, port their number to Al’s Phone Shenanigans LLC, and then find that their bank accounts have been compromised.
Actual Solution #2: Phone In A Drawer (my working solution!)
If banks have gone to so much effort to fight our attempts to use anything but “mobile” phone numbers for SMS MFA, then the most reliable solution is to stop fighting them and to use a real, genuine mobile number. The way this works is as follows:
- Before you deploy, activate your mobile number on a real, live, probably old, physical Android phone that you are not bringing with you to Antarctica.
- Install an app that allows forwarding text messages to email, such as Tasker or IFTTT. Configure it to automatically forward texts that it receives to an email address you can access in Antarctica. For IFTTT, you might consider subscribing to the Pro plan. This includes prioritized applet invocation, which will increase the likelihood that your SMS will be delivered to email fast enough for you to enter it into the MFA prompt.
- If your carrier or Google provides RCS chat features, disable them. We need to make sure that all messages come in as oldschool SMS, so that Tasker / IFTTT / whatever else can read them. RCS chats (the Android / carrier answer to iMessage) cannot be read by third-party apps.
- Disable all power saving features, notifications, automatic updates, etc. Set the app to “Unrestricted” Battery and background data usage. Disable automatic removal of unused permissions. Enable Developer Options and completely disable sleep mode when plugged in (you can still turn off the screen, but this ensures IFTTT can get SMS notifications in realtime). You want your phone-in-a-drawer to stay online, running without limitation, and safe from unexpected configuration changes while you’re gone.
- Plug it in, stick it in a drawer somewhere that has cellular reception, and volunteer one of your trusted stateside friends to keep an eye on it.
Note: IFTTT has two methods for sending email. The first, “Email”, will send emails through IFTTT’s email infrastructure. The second, “Gmail”, will send email using the Gmail API and your own Gmail account. This second solution, “Gmail”, seems marginally more secure. In both cases, the message goes to IFTTT’s servers, but with “Gmail”, the actual email goes out using your own Gmail account and bypasses IFTTT’s mail servers. However, I’m not sure if it makes a practical difference, because in both cases you have to trust IFTTT.
If you’re OK with sending using IFTTT’s mail infrastructure, and you want a one-click applet, you can use this one.
This solution seems absurd and convoluted, but it’s the only bulletproof way to actually get your text messages in Antarctica.
It’s the only solution that, from your bank’s perspective, meets their requirements. It’s a real mobile number, receiving real SMS messages, with no funny business. The only difference is – instead of you reading the message directly, there’s an app that reads it for you and forwards it to your email, which you can access in Antarctica.
Downsides here are numerous:
- If you want to bring your primary phone to Antarctica, you have to acquire a second phone, and transfer service to it at the last minute, which is an added expense and hassle.
- You need to have a place back “home” where your phone will be secure, powered, and online for the entirety of your deployment. If you’re living in an RV, boat, or treehouse, this might be tough.
- Your stateside contact needs to keep an eye on it and potentially troubleshoot if anything goes wrong.
- Your real live phone number is tied to a phone just sitting in a drawer somewhere. If it falls into the wrong hands, or your stateside contact goes rogue, it may be a security issue.
- You’re trusting IFTTT with your bank’s MFA codes. I trust IFTTT more than I trust Al’s Phone Shenanigans LLC, but that’s ultimately a decision you have to make.
However, if you’re willing to put up with these downsides and go through the hassle, I can confirm that this works, because this is the solution I’m using!
Conclusion
I hope this is a helpful (though admittedly tedious) overview of the current landscape for SMS MFA when you don’t have access to your physical phone.
There are a lot of silly hoops to jump through, and I imagine most people will settle for a compromise solution. However, if you’re determined, and if you have plenty of setup time stateside, this can be done.
