Cell phones have become mandatory authentication devices
I’ll put it bluntly - I do not want to use my phone to authenticate logins.
I take a minimalist approach to smartphones, using mine only for communication with others. I do not watch videos or browse the web, and I certainly do not access accounts (outside of email) on my device. However, as more services offer or require two-factor, my phone has been turned into an authentication device.
There are four common two-factor methods - phone (via call or text), email, authenticator app (TOTP), and physical key (U2F). I believe an authenticator app to be the most convenient method, as not only is this accessible from any number of devices it is configured on, it does not require any additional hardware to log in. This is also the most portable, as if the seed keys are saved, a new authenticator app can be easily configured in the event a mobile device is damaged, or the application is accidentally removed or reset.
The second most convenient is the physical key, such as a Yubikey. These keys authenticate with a touch of a finger and do not rely upon any software on the device. However, if the key is lost or forgotten, there is no getting into the account without using a secondary two-factor method, or by burning a recovery code.
Email is less convenient than the aforementioned methods, primarily because a well-protected email is secured with 2FA. To access the email, an authenticator app or physical key is required, creating a redundancy. However, some services require clicking a verification link, or copying/pasting a code with both letters and numbers, neither of which can be generated by TOTP or U2F.
Last and certainly least is phone authentication, one which I desipse with a burning passion. A code is sent via text message or phone call, and as such, the cell phone must be present when attempting to log into the account.
Inconsistencies between providers
In a perfect world, account providers would allow for any of these four methods to authenticate, but that is unfortunately not a reality. Some providers offer easy authenticator app and hardware key support, with a backup email available. Some providers only offer between an authenticator app or a hardware key for a seemingly arbitrary reason, though this is more of a nitpick than an impactful limitation.
The frustration begins when the provider does not support TOTP or U2F, instead forcing approval codes via phone or email. As stated previously, email is a less-convenient two-factor method for me. I still need to rely upon my key or authenticator app to log into the email to then access the code to log into my account. Additionally, my authentication is no longer contained to my preferred methods, and I must rely on an email service to serve me the auth code. Although it is highly unlikely, said email provider could experience an outage or shut down, and I may then struggle to access any associated accounts.
Worst of all is when phone authentication is the only method, doubly so when it is tied to a financial institution. A phone can break, can lose battery, and can lose service, and in any one of those cases, there is no way to access the account until the device becomes operational. If a device is lost or stolen, a new SIM card or eSIM must be accquired from a carrier, causing further delays. What a truly cumbersome primary method of authenticating on any device other than the phone itself.
How is this solvable when “just don’t use SMS two-factor” is not a solution? Such a question is not easy to answer.
VoIP email routing
VoIP providers such as Twilio or Telnyx allow incoming SMS messages to be routed to an email address. This solution proposes that two-factor SMS be sent to a VoIP provider and redirected to email. Although a key or authenticator app still cannot be used, a phone is not required.
This is not a fitting solution for me. Twilio can be complicated to set up and use. Twilio can also terminate an account at any moment, cutting off access to the rented VoIP numbers. This argument can be made against an email provider and carrier whom I also “rent” from, but they may less likely to terminate an account than Twilio may be towards a non-commercial single-user account, though this is just speculation.
Google Voice could also be used as a VoIP provider and supports message routing to email. Google Voice also has a web interface access portal if routing for some reason does not work. Given my concern with their data collection, I have not had a personal Google account for years now and will continue to refuse to use such services.
Dedicated mobile device
Using a dedicated and preferably small smartphone, phone-based two-factor authentication requests can be sent to a separate SIM card. This device would only be used for authentication and has the benefit of supporting other proprietary authentication apps that were not mentioned in this post. However, this defeats the point of not relying upon a phone for two-factor.
Virtual mobile device + VoIP messaging app
This idea is to be rejected as quick as it was presented. This proposes using an emulated Android phone (via Bluestacks or similar) to recieve messages via a VoIP messaging app such as MySudo. There is great risk in using a VoIP messaging app for account authentication as if/when the service closes or has its VoIP numbers terminated from their VoIP provider (Twilio/Telnyx/etc), there is no way to access the number. Look to the VoIP email routing solution instead.
I’ll need to explore these solutions more before deciding for myself. This post may update.
The inconsistent state of two-factor options is certainly frustrating. Providers should seek to provide additional means of authentication and move away from the SMS-based method. Although SMS may be viewed as convenient when accessing accounts on a smartphone, I have found it time and time again to be the most inconvenient for my computer use cases.
Please just let me use my Yubikeys.
It was pointed out to me by a friend that another means of authentication (which I am fortunate enough to not have encountered) is app-based authentication on a mobile device. I have encountered this with Steam Guard in the past, though it is not a service which requires frequent authentication.