One of the main criticisms of any advanced authentication system is usability. In FIDO2 multi-factor authentication (MFA), platform authenticators aim to be the answer to our usability woes, but do they improve the user experience and are they enterprise ready? In this article, we’ll dive into the world of FIDO2 authenticators, the problems that still exist and how these create major roadblocks for enterprises widely adopting FIDO2.
First came the tokens
Universal Second Factor (U2F), the predecessor to FIDO2, came into existence before it was common for laptops, tablets, and phones to have biometric capabilities such as facial or fingerprint recognition. These devices also lacked any sort of secure crypto-coprocessors (often called “Secure Enclaves” or TPMs).
The promise of U2F, much like what FIDO2/WebAuthn brings today, was to deliver fast, un-phishable authentication based on strong cryptography for all web users.
To use strong cryptography, you need a good place to store keys. The form factor of U2F is a hardware token or a “Security Key”: a physical device that guarantees you have a secure place to store private keys. The private key never leaves this device.
But how do you use one of these devices with your web browser?
The Client-to-Authenticator-Protocol (CTAP) was born. It formalized how a web browser (the client) would speak to an authenticator (the hardware token). The first versions of these devices only supported USB, but CTAP can theoretically work over any “trusted” medium like Near Field Communications (NFC).
The advantage here is that you clip this device to your keychain. It “roams” with you, wherever you go.
Unfortunately, the downsides are usability and cost, as well as the followings:
- Expensive to procure and distribute to the entire workforce
- Another device an employees need to carry with them (and can lose)
- Poor user experience – just a blinking light to tell you when to tap the button
- No ability to apply security/software patches
Something you already have
FIDO2 improves on U2F in many ways, but arguably the most important is the introduction of the platform authenticator, which aims to solve the usability problems.
A platform authenticator is a software “Virtual Security Key” built on top of a platform (such as iOS or Windows) that has access to an embedded secure crypto-coprocessor. iOS has the Secure Enclave; Android devices can have “Trusted Platform Modules” (TPM); some MacBooks have TPMs built into the TouchBar; and some Windows machines have TPMs.
The user experience is world-class. The browser (Chrome, Safari, etc.) interfaces with the secure enclave and biometric module to authenticate you. From a user’s perspective, all they need to do is touch the fingerprint sensor or look at the camera, and they are “magically” logged into a web app!
All the rough edges of a security key melt away, and the user just needs to do what they do a hundred times a day: authenticate to their device.
While platform authenticators are a huge leap, they still have major barriers to adoption within the enterprise.
You can’t take it with you
One fundamental problem (or perhaps a feature, depending on your viewpoint) with platform authenticators is that keys are not portable. They can only ever be used on the platform for which they were created. This means that if you register a credential on Chrome on your MacBook, you can never use that same credential on a different device. In fact, you cannot even use the credential in Safari on the same MacBook!
In practice, this creates a big problem. How do I securely authenticate with FIDO2 on my iPhone if my only FIDO2 credential is a platform authenticator on my MacBook? The reality is that this forces websites to support other forms of authentication (such as SMS codes), which opens the user up to a phishing attack by way of factor downgrade.
It’s not everywhere
The next problem for enterprises is that platform authenticators are not available on every device. For example, Apple iMacs and non-TouchID MacBooks don’t have TPMs and do not support FIDO2 in the browser by default. Unfortunately, this is a massive roadblock because it means IT organizations will have a fragmented deployment and complex enrollment flows.
Evolution: A roaming platform authenticator
So, we have these two authenticator technologies: a roaming security key and built-in, software-based, crypto-coprocessor-backed platform authenticators. Neither are enough on their own, but by taking the best parts of both, we can create an authenticator that is secure, easy-to-use, and practical for enterprises.
There is ongoing work in FIDO2 to expand roaming authenticator support to a network transport. This would extend the CTAP protocol to communication to an authenticator over an internet connection, but this is still in prototype and ideation stages.
A solution like this would let us use a mobile phone as a roaming authenticator, thus bridging these two worlds. Authentication on the web is evolving and with the right FIDO2 authenticator we can make strong, un-phishable credentials ubiquitous.