Further steps towards passwordless adoption.
The latest front in the war on passwords was opened recently via a multi-pronged attack by the FIDO Alliance, Apple, Google, and Microsoft. The announcement by the FIDO Alliance on the introduction of “passkeys” (or “multi-device credentials”) has been met with excitement by the Identity and Access Management community. At ForgeRock, we have been passionate about helping reduce the burden of passwords, and fully support these moves.
The announcement means that WebAuthn credentials created on Apple, Google, and Microsoft devices will be stored on their respective cloud servers, and associated with the user’s account. These keys will then be usable for other devices running on that same platform, reducing the need to register each individual device to a service, and increasing the spread and adoption of passwordless authentication. However, it brings with it some questions around attestation, and the potential for further sharing of these keys.
FIDO Alliance and WebAuthn
ForgeRock recently rejoined the FIDO Alliance—an industry association which has tasked themselves with developing and promoting strong authentication standards—to help expedite user adoption and implementation best practices. The FIDO Alliance’s most well-known success has been through their WebAuthn specification, which allows users to log in to services by simply pressing a button on a USB stick or using biometrics. WebAuthn eliminates the need for passwords, replacing them instead with a simple demonstration of ownership of the authenticator device.
Adoption of WebAuthn has benefits for both consumers and service providers. The consumer has one less password to manage and increased security through the use of a multi-factor authentication process and the phishing-resistant properties of the standard. The service provider from not having to store a password—even in salted and hashed form—thus reducing their value to potential attackers.
Passkeys Announcement
The announcement by the FIDO Alliance took the form of a commitment from Apple, Google, and Microsoft to:
-
Allow users to automatically access their FIDO sign-in credentials (referred to by some as a “passkey”) on many of their devices, even new ones, without having to re-enroll every account.
-
Enable users to use FIDO authentication on their mobile device to sign in to an app or website on a nearby device, regardless of the OS platform or browser they are running.
This means two significant short-term developments, and points to further iterations to come. The three big players have announced that keys minted on their devices will have the ability to be stored in the user’s ecosystem-cloud account (e.g., Apple account on iCloud), and made accessible by any device which is currently authenticated to that ecosystem-cloud account. Additionally, they have announced that in order to enable mobile devices to be used to share these keys out to devices outside of their platform’s ecosystem, these devices will act as WebAuthn authenticators moving forward.
WebAuthn Before Passkeys
ForgeRock Identity Cloud and Access Manager products have supported W3C WebAuthn since 2018. WebAuthn grants users a phishing-resistant, passwordless means of authentication which relies on the activation of an authenticator to prove ownership of a private key. These authenticators have both hardware and software implementations, and are most often interacted with as either embedded biometric features of a device (e.g., Face ID on iOS, Touch ID on Mac OS, or Windows Hello) or as standalone hardware tokens (e.g., Yubico’s Yubikey range).
In current deployments of WebAuthn, the private keys used to prove ownership of a second factor device are locked down. They are locked to the domain of the service to which they are registered, providing the phishing-resistant qualities of the standard. Additionally, they are locked to be accessible only by the specific hardware that originally created the keypair. This restriction means that for each service and authenticator device used, a separate keypair is minted and stored.
Registering multiple authenticator devices to a service is recommended, as protection against losing any individual device. However, this does mean a proliferation of keys. While each device must store a private key for each service, the service must store a public key for each device. Registering multiple devices can be burdensome. Forgetting to register a device can be catastrophic.
The recent passkeys announcement takes steps to address this issue, though it also brings with it the potential for a new set of issues which need addressing.
WebAuthn After Passkeys
The ambition of the announcement has not quite been matched by the commitments from the vendors in their initial comments on their implementations, though it should be noted that this is the first iteration of passkeys and further updates and features are coming.
Multi-Device Credentials
Apple, Google, and Microsoft have announced that keys minted on their devices will have the ability to be stored in the user’s ecosystem-cloud account (e.g., Apple account on iCloud), and made accessible by any device which is currently authenticated to that ecosystem-cloud account.
While this means that an iPhone user won’t have to individually register their other Apple devices to each service, this first stage does nothing to cross the ecosystem boundary. The vendors appear to have interpreted the phrase “many of [the user’s] devices” to mean “devices which are authenticated to the same ecosystem-owned account”.
This is only the first step. Many folks have a set of devices each from different manufacturers - an Apple laptop, a Microsoft Windows home desktop, and a Google Android phone. For these people, this first announcement brings few benefits. Each device will still have to be individually enrolled. The notion of ‘passkey providers’ has been mooted, which would allow for a third-party service to operate in supplying passkey directly to any device in an OS-agnostic fashion. Whether Google, Apple, and Microsoft will allow their ecosystem-cloud accounts to act as ‘passkey providers’, or if we will be fully reliant on smaller players to fill this gap remains to be seen.
Attestation Concerns
A second issue concerns the value of attestation data supplied by cloud-stored passkeys compared to those which are locked to a single device. Attestation data sent from an authenticator can be used by a server to determine whether the device is of a type trusted by the service. All authenticators of a similar type will be signed by the same attestation certificate. In a workforce deployment of WebAuthn, a service may decide to restrict the set of acceptable credentials to those which are accompanied by attestation data indicating a specific brand and type of authenticator being used.
So far in the announcements around passkeys, the manufacturers have said that no attestation data will be supplied along with those keys which leave the authenticator device. This may lead to issues with deployments, and ForgeRock will be closely monitoring developments around attestation data. The ForgeRock platform makes it easy for authentication and attestation data—if included in the response—to be interrogated during the authentication journey, so journey designers are in control of the flow no matter where the keys come from. In cases where there is no attestation data supplied, ForgeRock’s SDKs support adding device profile information to the data collected during authentication for analysis.
Potential Concerns
A third concern that has been raised around the adoption of passkeys is the reliance on the ecosystem-cloud account. Because passkeys are synced to all devices connected to a given ecosystem-cloud account, if a malicious user is able to authenticate to that service they will be granted access to all passkeys that user owns. Arguments have been made that this reduces the account security of any service to that which the ecosystem-cloud account supports. ForgeRock’s Intelligent Authentication journeys makes it simple to augment WebAuthn with additional authentication factors to mitigate the risk of a compromised ecosystem-cloud account.
Moving Forwards
In conclusion, passkeys are a significant improvement in the user experience for those users who are already ecosystem-locked. For services, it means storing fewer keys per user, at the cost of losing attestation data. In the CIAM world, this should be considered an easy win, workforce deployments should consider their need on an individual basis.
ForgeRock will track developments around passkeys as they emerge. Testing to confirm interoperability with passkeys, which are based on the same standards as WebAuthn, is underway. To support customer choice, ForgeRock aims for configuration options that allow a deployment to accept or reject passkeys, and whether or not to allow for an authenticator to transmit a private key up for cloud storage as a passkey. Additionally, due to concerns around the weaknesses of the cloud account where passkeys are stored, ForgeRock recommends supporting WebAuthn with intelligent decisioning and dynamic journeys, as well as the implementation of zero trust principles throughout the course of a session lifetime.
Helpful Links
• Identity Cloud > Authentication and SSO > MFA: Web Authentication (WebAuthn)
• AM 7.2 > Authentication and SSO > MFA: Web Authentication (WebAuthn)