The Problem(s) with Multi-factor Authentication

Author: Rob Black

Back in 2007, with the company that I was working for beginning to circle the drain, it became clear that it was time for me to move on. That’s when I joined RSA Security (my first official foray into the wonderful world of cybersecurity!) and began working on SecurID, RSA’s Identity and Access Management (IAM) product.

IAM focuses on exactly what it sounds like: Identity — verifying who you are through password, thumbprint, driver’s license, etc., and Access — based on identity, providing an appropriate degree of rights and permissions for logging in, making changes, etc.

At the time, cyber as a field was way less developed. A large part of our focus was Multi-Factor Authentication (MFA), but back then, there was no such thing as a Google Authenticator app or similar consumer product. RSA still owned the patent for time-based, One Time Password (OTP); nearly every large company used RSA’s SecurID to protect its infrastructure.

MFA Goes Mainstream

Fast forward 15 years to today and MFA is everywhere. And, happily, it is easy to manage.

Okay, it is not easy to manage.

And that can be problematic, since despite its limitations (more on that below), many companies require MFA (as they should) for you to gain access to various web sites and applications. For example, your bank probably makes you authenticate with a text-based OTP each time you log into online banking.

Here’s where the problems begin. Text-based authentication is not that convenient. What if…

… I can’t find my phone?

… I changed numbers?

… my phone is dead?

… there’s no cell coverage?

… the message is never sent?

… the message is sent but super-delayed?

It gets worse. Text-based authentication is not just inconvenient, it’s also not secure. The messages are not encrypted and attackers can (relatively) easily gain access to them (if not the phone number itself) through SIM swapping or Text Intercept (SS7 Attack).

A much better solution is a purpose-built MFA application such as Google Authenticator, Twilio Authy, Duo Mobile, or Microsoft Authenticator. These applications scan a QR code from a website and then store a matching “secret” in the application that is associated with you. A new code is generated every minute which you then type into whatever application or web site you are trying to log into.

Better, But Not Perfect

Authenticator apps solve many of the text-based problems described above, in terms of both convenience and security. However, there is one tiny problem with them… you still need a charged phone in your possession in order to get the everchanging OTP!

Over the weekend, for example, my phone went 100% dead. I couldn’t revive it or even charge it with tricks from the Internet. Uh oh. I have dozens of MFA applications that allow me to log into the many SaaS applications we use for ourselves and our clients. Without a working phone, I was cut off from all of them.

Fortunately, Apple was able to recover my phone by cleaning out the port and doing a hard restart. But what #Apple did not repair was my fear of how much work I would have had if my phone had been truly unfixable.

Business Continuity Requires Preparation

My situation is by no means unique. Unlike consumer web sites for which there is a reset path if the authenticator app is lost or unavailable, the same is not true for many business applications. For small companies in particular, access is often in the hands of just a couple of people. If one of them is on vacation and the other loses their phone, things can get complicated!

So, given my weekend scare, I have committed to following good business continuity. I suggest you do the same. Some thoughts on how…

#1. Take a screenshot of the MFA QR codes.

NO! This is NOT okay!! As soon as you have cryptographic material in your photos, you can expect that data to be replicated and seen by many people / programs. This may defeat the purpose of MFA.

#2. Copy the codes onto the phone of a trusted person.

A spouse, for example. This is probably okay for personal purposes, but companies are likely not comfortable with non-employees having access to codes that authenticate their systems.

#3. Copy the codes onto a tablet or backup phone controlled by the same person.

This is what I have now done and it’s probably the best option.

It’s workable, but a bit tedious: You can export QR codes from one device to another, but usually only in groups of about ten. Plus, as new codes are added, you may need to replicate the entire process to have a complete backup.

And, ironically, these apps — whose only purpose in life is to enhance security — don’t consider the export of their own codes to be a “privileged function.” Doing so requires no reauthentication, nor is an email alert sent indicating that an export has occurred. Sigh.

Fortunately, there are better solutions on the horizon, including FIDO2 and WebAuthn. These solutions are not yet mainstream because of technology and logistical issues, but many of these will be ironed out in the next few years.

For now, make sure you are using MFA everywhere, with an authenticator app instead of text-based MFA when available.

Gotta run; I am getting a text from my bank with the 6-digit code I requested two days ago…

Want to get great cybersecurity content delivered to your inbox? Click here to sign up for our monthly newsletter, Tales from the Click.

Rob Black, CISSP

Rob founded Fractional CISO in 2017 and has helped dozens of companies improve their security posture as a vCISO. He consults, speaks, and writes on IoT and security. Rob has held product security and corporate security leadership positions at PTC ThingWorx, Axeda and RSA Security. He received his MBA from the Kellogg School of Management and holds two Bachelor of Science degrees from Washington University in St. Louis in Computer Science and System Science and Engineering. He is also a Certified Information Systems Security Professional (CISSP).