For as long as I have been in the security industry, a good quarter of a century, the conundrum of security versus usability has reigned. Attempts at redressing this balance have arisen. Mobile-based authentication has been added to the security armory of both the consumer and the enterprise login credentials. Further attempts at hardening login whilst balancing usability, have seen the advent of biometric authentication methods; all attempt to cope with the infinite “phishability” of the humble password. Yet still, authentication remains the bugbear of the consumer and the identity industry.

The FIDO Alliance has been working to crack this security/usability riddle since 2012. Until now, their efforts have been chiefly aimed at the enterprise. However, as consumer identity and remote working creates a fuzzy identity landscape, FIDO has turned its sights on fixing authentication for consumers.

FIDO moves into the consumer space

FIDO (Fast Identity Online) entered the authentication landscape in 2012 in the form of an alliance of parties with a vested interest in online identity and authentication. The initial consortia included PayPal, Lenovo, and Nok Nok Labs. Since then, more big tech companies such as Google, Microsoft, Twitter and Amazon have engaged with the group. The remit of FIDO was to replace passwords with something more robust and easy to use: a great ambition in a world where passwords are a gift to phishing.

The FIDO Alliance works on standards to replace passwords. In 2018, FIDO collaborated with W3C to deliver WebAuthn authentication. WebAuthn is an API that provides the support needed for web developers to update their login pages to add FIDO-based authentication. FIDO2 is the latest version of FIDO that includes Client to Authenticator Protocol (CTAP) as well as WebAuthn. CTAP provides support for authenticators, including mobile devices that interface with browsers and operating systems that are FIDO2-enabled.

Fast-forward to March 2022: FIDO announced the publication of a paper that shows how the alliance will facilitate true passwordless support for consumer authentication.

FIDO has a vision: an internet that is secure but has easy access to resources. The door will be open but the latch is always on. The financial sector is a great example of an industry that knows it must be secure but must weigh up a great customer experience with robust security. Steve Jobs also understood this: “You’ve got to start with the customer experience and work backward to the technology,” he is famous for saying.

In the world of consumer identity, the omnichannel is king. The modern customer typically uses six touchpoints, according to research from Oracle. One of the downsides of earlier versions of FIDO was the lack of support for the types of channels used by consumers – hence why FIDO tended to be more of an enterprise choice as device use could be more controllable. However, the COVID-19 pandemic and remote working have focused the minds of us all, FIDO included.

In this latest announcement, FIDO has set out its stall and identified key weaknesses in the design of earlier attempts at a passwordless internet stating:

“… a challenge that persists is the requirement that users enroll their FIDO credentials for each service on each new device, which typically requires a password for that first sign-in. So what happens to your FIDO login credentials and how do you recover your account if you change your phone or laptop? They are not recoverable in today’s FIDO model. This presents issues for deploying FIDO at scale to consumers who are constantly moving between devices and updating to new ones. This is less of a challenge in the enterprise, where companies can solve this issue by deploying internal management tools used to support passwordless authentication, and for employees to recover accounts and credentials.”

The above statement encapsulates, not just the challenge for FIDO, but all consumer authentication options. In consumer authentication you are often damned if you do and damned if you don’t:

  • Consumer authentication systems that only use a password are vulnerable to phishing.
  • Consumer authentication systems that offer two or more factors (MFA) are annoying to consumers, can be complicated to implement, and can be costly to the host if based on SMS text messages.

FIDO means to fix this issue, once and for all. But will it, and is it enough to drink from the golden chalice of consumer authentication?

What ifs that FIDO must address for consumers

In 2018, I wrote an article for CSO, “Will WebAuthn replace passwords or not?”. I said in that article that “As always, the devil is in the details.” One of the areas I picked out as a potential problem for general users is the “what if” scenario, for example, what if you lose your phone. Losing a phone or damaging it beyond repair is not an edge case, it happens a lot, but WebAuthn and FIDO2 did not have a suitable and easy fix for this problem.

This latest update from FIDO Alliance looks like it has taken the “what if” scenarios onboard and is attempting to address them. This is great news. Some of the details on “what ifs” include:

Phone as a roaming authenticator

The FIDO/WebAuthn protocols define that a user’s phone can communicate with a FIDO-enabled device via Bluetooth. Because of the proximity requirements of a Bluetooth connection, FIDO has defined this as an anti-phishing mechanism. There is also a facility to upgrade existing mobile-based, two-factor authentication options, to add this new anti-phishing security layer to existing setups.

Multi-device FIDO credentials and new phones

FIDO outlines support for the seamless transfer of FIDO credentials when a phone is replaced. However, an important caveat that may impact this is that FIDO has not made a change in the FIDO standards. Instead, they are leaving this support up to the authentication vendor and implementor.

FIDO also points out that the user experience will be akin to using a password manager. I add a word of caution here: The uptake of password managers is still very low, possibly because of usability issues. For FIDO to use a password manager as an example of improving the usability of FIDO should be seen as a design warning bell.

What if a device is unavailable?

The FIDO “passkeys” will be able to sync among devices. So, if a device is unavailable, another FIDO-enabled device should have the correct credentials available. FIDO points out that the security of this mechanism is dependent on the underlying operating system and account security of the device.

New device and double-check security

FIDO has thought about the “what if” of a new device with a synced credential accessing a high-value resource. FIDO has added an extension to the protocol that provides a facility for uplift, a request for another device-bound cryptographic key to be created on the new device. This will require a relying party to implement their account recovery mechanism.

Relying party choices

The relying party, in all scenarios, must have an easy ride to ensure that FIDO is implemented correctly. FIDO comes down to two choices:

  1. Rely on synced FIDO credentials. (This ties security to the authentication security and account recovery procedures of platform providers.)
  2. Use FIDO with device-bound signals based on the device-bound-key FIDO extension.

What if, FIDO?

Going back to what Steve Jobs said about customer experience must lead to the good design of software systems. FIDO is working to provide flexibility in its protocols and API use that fit the “what ifs” of a consumer model. Many of these what ifs require a keen eye for implementation detail.

However, good security is always as much about implementation as it is about protocols and functionality. In the case of consumer authentication, a good design will be needed to capture the many convoluted use cases of modern authentication across omnichannels. Not least of these user journeys is account recovery, which FIDO place in the lap of the implementor if choosing the device-bound-key option. Ultimately, consumer identity is typically tied to complicated, multi-faceted systems, and only with good protocol support can architects and system designers close the conundrum doors that keep security and usability apart.