Overcoming Authbarrassment
Multifactor authentication (MFA), of any kind, has long been deemed essential in the era of both en-masse and cleverly targeted phishing. No surprise then, that the arc of adoption for multifactor authentication has been very much an ‘up and to the right’ affair.
On the surface, it sounds like an extremely happy tale to tell. A risk (phishing and the compromise of a password) was identified, a mitigation (MFA) was proposed and widely adopted, albeit perhaps not quite as quickly as we’d like in some cases, but still — baby steps, and all that.
Sadly, the story doesn’t quite end there. Even when a business puts MFA support into their product, a worrying new trend seems to be lurking, a trend I like to call ‘Authbarrassment’.
Let me explain.
First of all, some apps offer optional MFA, which is better than no MFA, but as we all know the reality is folks take the path of least resistance to get to what they need, and unless explicitly required to enable MFA, many simply won’t. This is the root cause that allows authbarrassment to exist as a condition in the first place.
Authbarrassment occurs when a user, who has taken the time to enable MFA on an application that optionally supports it, is prompted to disable that MFA on every single log in. It’s as if the application is so embarrassed by its own MFA, it wants the user to ditch it just as quickly as they enabled it. In some cases, a single tick box without further confirmation is all that is required to do so.
Here are a couple of examples of authbarrassment in action:
This screen pops up each time you successfully authenticate to this large insurer’s app, a single tick box can be used to disable the MFA feature: ‘use a verification code EVERY TIME I LOG IN?’
In this cellphone provider’s app, you’re given the option to disable MFA on each subsequent log in.
In both these apps, MFA has been enabled, and is easy to leverage during the log in flow, yet on every log in the app acts like the naughty kid on the school playground, trying to lure another away to smoke cigarettes behind the bike sheds, “Hey nerd, turn off your MFA, all the cool kids are doing it! All it takes is one tick box and I’ll do it for you.”
What this condition reeks of, is a behind the scenes dynamic in which the enterprise security team has insisted MFA be offered, but a UX designer, or a product manager isn’t happy with the supposed barrier this creates to user engagement with the product, so puts an ‘easy out’ button right there on the front door. No surprise that the two examples I’ve shown above come from larger organizations, where it’s more likely that these groups have never interacted using a mechanism beyond ever elongating email threads. To clarify, that assumption is based solely on my knowledge and experiences, I have no way of proving that hypothesis, but if I needed to, I’d like my chances.
So how can we kill off authbarrassment once and for all? How can we tell the companies we do business with, actually, we like MFA and are not embarrassed by it?
Keep providing app feedback — most apps provide a mechanism to do this, and most feedback is read and triaged. If you include the term ‘security’ in such feedback, often it’ll find its way to someone in a security team as this is required by a guideline or standard.
Let the data tell the story — prove that good security isn’t a barrier to a good app experience. If you go through a decent MFA authentication process, carry on using the app. All your clicks are going to make it into a behind the scenes analytics tool, and if the data shows that MFA doesn’t disrupt engagement, that argument goes away.
Ditch apps that have poor security — If your chosen app or service doesn’t support MFA, yet has any amount of your information in it — it’s 2019, put that app in the trash!
Let’s end the stigma associated with enabling MFA in an app that makes it optional to do so. Let’s end authbarrassment, together.
