A bazillion keys
This is my favorite and most interesting “new” problem that is not new 😊.
One of the defining characteristics of Webauthn is that it requires a distinct key pair for each resource and each client device. This provides the advantage of privacy that comes from non-correlation across sites, but it also multiplies the number of new keys we’ll be dealing with, exceeding even the number of passwords each of us has today.
A world of widespread Webauthn/FIDO2 deployment will be one of approximately “one bazillion” keys across platform and roaming authenticators, users, devices, and relying parties. This creates the potential for a key management nightmare.
And unlike the mixed bag of API keys, tokens, confidential client secrets, passwords, and you-name-it that can be managed by a Secrets Management solution, these new keys will be user keys vs machine-to-machine keys. So these keys will require user experiences not only for usage, but for other common tasks we will need to perform to be able to use our keys easily. The problems are a bit more than simple create, get, list, and delete on a given authenticator.
We will need solutions to common situations like:
Oh shoot, which key did I use for this site and which authenticator device does it live on?
Do I have a backup key? Is it up to date?
I have keys across authenticator devices, computers and phones. How can these keys be kept track of?
What if I need to revoke or invalidate a key?
I have a new phone and want to provision keys on the platform authenticator for a large number of accounts all at once. How can I do this easily?
What if I lose my phone, which has a lot of keys on it?
Before leaping to “the user shouldn’t have to know” and “we’ll do it all behind the scenes silently”, please recall from Principles of Good Auth, where I said that access control decisions need to be explicit because, amongst other things, the “friction” or trouble taken to interact with [our keys] has a good result – it trains us to make better choices.
So let’s talk about some concepts and patterns for implementers and enterprises to help us have the right credential and key management solutions for the world of a bazillion keys.
Optimizing Key Issuance
The first way to mitigate this proliferation of keys is to ensure keys are enrolled in an efficient way so that we don’t have more keys than we need, but we have sufficient keys to cover the access scenarios. This is of course in the control of the websites / relying parties who support key-based sign in. Here are a few things they should think about:
Platform vs roaming authenticators. A platform authenticator – on the user’s phone or laptop – is going to be the most convenient to use for day to day sign on. A user will likely enroll more than one of these. A roaming / “cross platform” authenticator (a.k.a. a security key) can connect to a laptop, phone or other device, providing multi device support as well as a backup key.
Use of identity providers as aggregators. There are two ways for a relying party to support Webauthn sign in: either natively, consuming and validating Webauthn assertions, or via federated single sign on from identity providers (IDP) who support Webauthn. In the latter case, the website simply needs to support the federated authentication method – SAML, OAuth, etc – that the identity provider supports. How should websites and apps decide which approach to use? To answer this question you must consider the weight with which your app or service values privacy / anonymity of users vs the efficiency of simply pointing to an IDP. Also, what is the cost of implementing Webauthn natively, and taking on the management of all of your users’ credentials, vs outsourcing that task to an IDP?
Use of resident/discoverable keys. While the choice of resident or non resident keys doesn’t affect key proliferation (the keys still exist no matter where they are stored), this implementation choice does affect key management scenarios, mostly because taking on storage/protection of a private key shifts a management burden from the user to the relying party, both in terms of allocating capacity to manage the keys and in terms of protecting private information.
Implementation: Key and Credential Management Experiences
So, which key management scenarios and capabilities are most important? This is of course up to the implementers, but here are some thoughts from me about which are the most imperative:
For Webauthn supporting websites / relying parties
Enable enrollment of multiple factors, including of multiple Webauthn factors, to ensure a backup device can always be enrolled in advance of more seamless backup capabilities emerging in the industry.
Consider collecting a “hint” at Webauthn registration time to help the user recall which device (phone, security key, or laptop for example) to use at authentication time.
Provide easy, user-driven key management via self-service.
Provide flexible recovery experiences in case of loss of a key, and surface meaningful information when there are multiple available authentication methods or credentials for a sign in.
Consider providing user-elected sign in method preferences, such as per-device default methods or last-successfully-used method as default for next sign in from a device.
For authenticators (platform or cross-platform)
Ensure authentication devices and platforms provide basic enumeration of which relying parties / users have been enrolled on the device (gated behind PIN/Biometric as appropriate for spec compliance). For example, Yubikeys with firmware version 5.2.3 or higher offer this via the Yubikey Manager command line “ykman fido credentials list”. This applies only to resident credentials in the Yubikey case.
For non resident credentials, the above is not feasible today because no information is stored on the authenticator device. However, if we expect the non-resident pattern to be used widely going forward, the industry should consider paving new ground by enabling the above for non resident credentials as well, based on a mapping of which relying parties this key can decrypt keys for (again, respecting and mitigating security/disclosure issues by requiring PIN/Biometric).
A note on backups of Webauthn credentials/keys
While manually enrolled hardware backup keys, and new cryptographic schemes to make maintaining those keys easier have been proposed, my gut is that a backup solution that requires incremental effort on the users part, is not going to be adopted widely enough to be valuable, and that cloud-based backups will be a more successful path. While it pains me to defeat the purpose of the private key by sending it across the internet for storage at a cloud provider, the existence of non-resident keys in the Webauthn world means that we’ve crossed that bridge already, so we may as well enjoy some further benefits from it
So now the only remaining question becomes – who should take on the key backup? It will be fragmented and difficult for each service / RP to take on backups for its own credentials, and it won’t solve the problem of “have I backed up all my creds” for the user. IDPs could do it, but not every credential is an IDP credential. This leaves technology and security companies, who have both the expertise to backup keys safely and the relationship with the authentication device(s). Microsoft, Yubico, Google, Apple, Okta etc all have the security depth and technology breadth to execute successfully on an offering to back up (and manage) users’ keys easily. And any company who has a credible authentication app would have a great entry point to introduce such a service. It would then naturally follow on from a key backup service, that a new-device-provisioning experience could then be provided, as well as other key management experiences (what keys do I have where, etc).