We use routers to move IP packets across the Internet and toasters to get crispy bagels. There are all kinds of brands, versions, and management features, but overall, routing and toasting each use a single technology. Authentication does not, especially when it comes to multi-factor (MFA or 2FA). Why is that, and is Mobile the platform where authentication will eventually converge?
Password-based authentication, SMS-based authentication, token-based authentication… The jungle of user authentication
The “ownership” factor or “something you have” is a set of seeds and keys stored with something you carry with you. That ‘something’ used to be a keychain token or a card (similar to a credit card) with a chip or a display on it. It’s now your phone and more specifically either an App on your phone (which in turn could be an authentication App or just an authentication module within an App), or a secure element in your phone (removable or built-in), or by extension, just your phone associated with your phone number so that if you receive a text or a call-back on that number, only you are able to access it. It can also be your tablet, your computer, your smartwatch, or whatever the next connected thing that can store identity keys might be – a badge, a wristband…
This already vast diversity is augmented further by the “inherence” factor or “something you are”, i.e. biometry. Some trait of the person trying to access is captured and compared to a stored version initially captured for the legitimate user. The capture can be done by a specialized sensor such as TouchID introduced by Apple on the iPhone in 2013, or iris scanners, or vein scanners… However, as standard sensors such as cameras, microphones, and touchscreens get more precise, the capture will increasingly be done through software processing these standard sensors outputs.
Mobile, a much less expensive authentication platform
So, this is the jungle of secure authentication. Unlike tastes and colors that are a matter of personal choice and therefore not a topic for a fact-based discussion, secure authentication solutions can be classified and compared. It’s generally admitted now that the main criteria to consider for a multi-factor authentication solution are – in order of appearance – security, costs, and usability.
Mobile has become a default platform for multi-factor authentication (MFA) around 2010 primarily for costs reasons. Service providers initially, then businesses, found in Mobile MFA an escape road from the high costs associated with hardware-based tokens. The “consumerisation of MFA” couldn’t possibly happen at costs close to – or above – 50 USD per user per year, which was the typical price point when you had to purchase the tokens (in small numbers since they contained a battery with limited lifetime so that you would have to come back to your reseller very soon after the licenses had expired…). Mobile appeared as the obvious solution for organizations pressed to increase sign-in security by rolling out MFA. inWebo (founded in 2008) was one of the early startups created to help this transition to mass-market MFA. Mobile was a golden opportunity for these startups to disrupt the preexisting market by slashing its business model.
As a side note, the move to Cloud-based solutions that started around 2010 as well, wasn’t really motivated by additional savings. In cybersecurity as in any other IT area, Cloud-based has become a preferred implementation model for a number of reasons.
Security and usability didn’t initially benefit from Mobile 2FA
What about security and usability? These were clearly not the motivations for the transition mentioned previously. On the contrary, both the robustness of usability of MFA solutions significantly decreased.
The robustness decreased because the seeds and keys (the ownership factor), instead of being safely stored in a hardware-enforced secure element, were now some data stored by an App, not very difficult to copy or to extract by specialists. inWebo was a rare exception because of the complete redesign of the MFA algorithms, precisely in order to take into account that seeds and keys could be extracted in a software implementation of MFA. I’m not even speaking here about (mobile) SMS-OTP, codes sent to your phone at sign-in. It’s easy to bypass the need to physically “own” your phone.
The usability also decreased since instead of carrying a small display showing a dynamic code that the user had to copy and paste, she now had to find her phone – hopefully with some battery left -, unlock it, launch an App, select the right option or service, possibly enter a PIN, and finally display a similar dynamic code, but now much less immediately available. Worse, with SMS-OTP, you had to make sure that you had signal – or go to the right place in the building -, and even so, texts could take a minute or more to arrive on your phone.
But it’s getting better
Mobile was initially missing 2 important capabilities to become a good – and not only inexpensive – MFA platform: notifications and low-level (or even chip-level) sensor APIs.
Notifications are a modern, better supported, and free version of earlier ‘WAP-push’ texts. Waking up an App to prompt you for your PIN or just for your confirmation is a far much better UX (user experience) than what the first Mobile MFA implementations proposed – they were mere copies of the “token experience”. WAP-push texts were just not good enough.
The security has also improved with notification-based MFA, since it’s no longer vulnerable to phishing attacks and it can even be used to provide a satisfactory transaction protection against MITM/MITB attacks (Man in The Middle, Man in The Browser). The problem related to the software storage of credentials is also increasingly being addressed and solved. For example, Apple opened up its TouchID API to developers in iOS8 (September 2014). Samsung made similar move with its Knox program. This is by far not yet generalized, but the movement has started. Hybrid approaches like inWebo’s already provide very good robustness on phones that do not support such APIs, and use the APIs whenever they’re available.
How about the increasing support of biometry on phones? I consider it to be a better usability (replacement of a PIN) rather than a better security, since the biometric element can usually be reset with a PIN.
There’s still a usability flaw with Mobile 2FA
Less expensive (users bring their own tokens instead of organizations having to equip them), getting better in terms of usability and security… Mobile MFA has indeed improved a lot.
However, looking back in time, 10 or 20 years ago, what do we see? Mobile MFA is indeed much less expensive than MFA was back then – but you could argue that the high volumes needed for consumer-facing MFA would have pushed the prices down anyway. It’s getting better in terms of security, although a direct comparison is difficult to make. And it’s not really different in terms of usability – the multi-purpose phone has absorbed the security token, as it did before with watches, cameras, MP3 players, and so many more.
However, the initial flaw with MFA – that you need “something” to sign in to your services -, that flaw has remained there, unchanged. The plastic, basic ‘something’ has been replaced with a much fancier one. MFA is still stuck there. Can’t we do better?
How about secure authentication finally becomes a service
Remember when it was an intellectual effort to distinguish your email account from the computer where you had installed the client? Hotmail helped us realize that email is a service. The same way, Dropbox (and others) helped us see storage as a service. The same still needs to be done for authentication.
This is one of the early choices made by inWebo: each or your devices such as a computer, a tablet, a phone – and not just your mobile phone – can be turned to, and used as a trusted device. A trusted device is a device from which you use or manage your authentication profile.
How does it relate to the topic? How does it fix the UX flaw discussed previously? Imagine that your browser on your laptop or on your tablet (or on your smartphone) is a trusted device. When you sign in to a service requiring 2FA, you no longer need an extra token or phone, your browser does the job behind the scene. With a very similar level of security.
How often do you sign in from a browser on one of your computers, tablets, or smartphones? For myself, I estimate 99% at least. I’m not sure that I have signed in from a non-trusted browser in recent years, except when I initially registered the browsers on my newly-purchased devices as trusted browsers. With WiFi everywhere, we no longer have to use other devices to connect to our services when we’re on the move. “On the move” is actually hard to distinguish since tablets and smartphones – and now most laptops as well – no longer have Ethernet plugs…
Browser-based MFA “almost” solves the UX flaw. Not entirely, since there are still situations when we need a mobile phone instead. A service approach solves it: in most cases (99% for myself), users sign in more easily with their browser than they would with their phone, but still can use their phone as a trusted device for the remaining cases, such as signing in to an IPSec VPN client.
Mobile is therefore not the best suited nor the ultimate MFA platform, but it’s a must needed piece of an authentication service. As often, the problem was in the question itself; we overcome it by changing perspective.