Broadening the user base of WebAuthn

[agl]

WebAuthn is the Web standard that supports security keys: often physical USB tokens used as a 2nd factor for authentication. WebAuthn already supports being the only factor: browsers can display a list of accounts from a security key and the security key can collect a local PIN or biometric to verify that the correct person is present. But it seems unlikely that broad numbers of people are going to purchase a pair of security keys to use WebAuthn, and manage double-registering on all their sites.

Thus, in WebAuthn L3, the WG is considering several changes to make WebAuthn more broadly applicable as a password replacement and we would like to raise this with TAG.

• Explainer: https://github.com/w3c/webauthn/wiki/Explainer:-broadening-the-user-base-of-WebAuthn
• GitHub repo: https://github.com/w3c/webauthn
• Primary contacts (and their relationship to the specification):
  • Adam Langley (agl), Google
  • Akshay Kumar (akshayku), Microsoft
  • Anthony Nadalin (nadalin), Chair
• Organization/project driving the design: WebAuthn WG

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done: WebAuthn WG
• The group where standardization of this work is intended to be done: WebAuthn WG
• Existing major pieces of multi-stakeholder review or discussion of this design: Possible experiences in a future WebAuthn w3c/webauthn#1637

We'd prefer the TAG provide feedback as (please delete all but the desired option):

☂️ open a single issue in our GitHub repo for the entire review

[Myridium]

Sorry to butt in, but I have been reading a bit about w3c's WebAuthn activities and the approach is puzzling me:

But it seems unlikely that broad numbers of people are going to purchase a pair of security keys to use WebAuthn, and manage double-registering on all their sites.

First, whatever happened to the Asynchronous Remote Key Generation proposal by YubiCo which would allow users to keep a redundant security key backup in safe storage, consistently synced? The user has control over their own data and security this way; there is no need for online services to offer their own syncing mechanisms if the user has, say, 3 security keys to which they assign memorable names. It is easy to imagine this as part of a marketing campaign for a new passwordless experience-- naming your personal, private security keys that will never divulge their secrets to anyone. Call them "Bob, Roger and Frank" if you will. Physically label/engrave them too, if desired. Simple to understand, as well. As part of ARKG, the user's hardware tokens could be configured with the public keys of the other tokens, and easily enrol them as a matter of course in new services. Services can display a list of enrolled devices, and users know to check that "Bob, Roger and Frank" are all enrolled. Easy.

Only issue/improvement would be synchronising credentials across services. For this it seems easiest to use the Hedera network, where there could be a maintained list of keys for the user. For more privacy, the user could maintain their own private list (e.g. Hedera File Service), and issue NFTs to services in order to grant them access. How? The security key would have permission to mint such NFTs. This may sound futuristic and far-fetched and impractical, but it is actually achievable and cost-effective today. We just need trusted hardware key manufacturers like YubiCo to support biometric--protected on-board transaction construction and signing, for a painless experience. Admittedly there is probably a lot of work to be done developing compatible hardware keys. But it can be done.

Second, I think that the passwordless transformation will be more than sufficient to convince users to take that extra security step in managing a few hardware tokens. In fact I would go so far as to speculate that this relieves the user of a psychological burden, as a physical security key system is easy to understand and keep track of. If a private key is stored on my smartphone or PC, then I simply don't know how safe it is. Can it be hacked remotely? Does it expose the private key in RAM? (YES, therefore vulnerable to memory exploits, rootkits etc). If it's on dedicated hardware designed by a reputable brand, then I just needn't worry.

Users may even think of this transformation as returning to simpler times-- a physical key that unlocks accounts. You don't have the key? Then you don't have access. You do have the key? Well, I better change the lock (invalidate the key) but I won't worry too much because I know it's protected by my fingerprint.

I know I'm repeating myself, but I don't understand why it would be considered hard to onboard users to such a system. I am pretty sure my grandparents would have felt quite comfortable using biometric FIDO2 hardware keys. Usernames/passwords? Not so much.

I would urge W3C to conduct real usability studies (with real test subjects) with biometric FIDO2 keys, and usernames/passwords, to determine whether users would autonomously make the switch. This is too important for idle speculation.

If biometric-protected FIDO2 keys supporting ARKG are released, and ARKG is incorporated as a core of the WebAuthn standard, then users will have the ultimate usability experience; the cognitive burden of managing online identity will be eased; users will 'own their identity'; they'll retain privacy (assuming public keys are in some way 'salted' according to the online service; also consider Hedera), and the security of such a system will be quite substantial. I believe that users would understand this authentication system better than the current username/password based one. And I believe that users would autonomously switch due the great user experience.

A bright future in security and usability awaits, and it's really achievable today I believe. Please don't shoot us in the foot by settling for second best. Incremental innovation stifles adoption. The passwordless revolution is a rare opportunity to get things right, to perform a quantum leap in security and usability, with a high degree of confidence that users will autonomously onboard themselves and mainstream adoption will be achieved.

[torgo]

Hi @agl just wanted to ack this and let you know we are working on it. We plan to spend some time on it at our virtual f2f in 2 weeks' time and we hope to have some useful feedback for you after that.

[hadleybeeman]

Hi @agl. We are discussing this in our W3CTAG breakout today.

This has generated an interesting discussion, and we have a couple of questions you may be able to help with.

1. How safe are sync fabric providers? We talked through a number of scenarios in which this could fail to protect users:

• one where the sync fabric provider has access to the credentials themselves and abuses them,
• one where authorities could serve warrants on sync fabric providers and gain access to all of a user's accounts, and
• one in which an unscrupulous but widely-used site requires that users use their sync fabric to log in — and then they have access to all of that user's accounts.

Have you and the working group considered these types of scenarios? What sort of mitigations might be added to the spec or the ecosystem to protect users from scenarios like these?

2. Can you say more about device-key extension? We were intrigued with the protections that come from pairing syncable credentials in a phone or sync fabric to an automatically-generated, device-bound key pair. Would you imagine those keys expiring regularly (monthly or weekly, etc)? And while this clearly mitigates some of the danger to the user (their older credentials would no longer be available, should they be exposed or exfiltrated) — how much damage could still be done if credentials were leaked before they expire? And are there other ways to protect users in this scenario?

[agl]

How safe are sync fabric providers?
…
Have you and the working group considered these types of scenarios? What sort of mitigations might be added to the spec or the ecosystem to protect users from scenarios like these?

Starting more broadly, I don't think a W3C spec has much (any?) influence here. I would think of it in the same way as password managers. There are several, and probably people have opinions about their relative security, but I don't think that HTML5 would achieve anything if it, say, mandated particular designs for password managers.

Similarly, Web Authentication currently defines an interface for using security keys and typically those are separate physical devices or embedded secure hardware. But one can also flip a switch in Chromium's DevTools and store credentials in software for testing. Web Authentication does not (and should not) prohibit that. (Although it does include support for attestation that can effectively prevent it in enterprise environments.)

Getting more specific, I can only speak about Google's potential sync system here.

If Google were to build a sync system we would not wish to have access to the credential private keys. You can see public information about how Android Backup implements end-to-end encryption and thus how that might be achieved in this context.

(iOS and macOS can sync WebAuthn credentials via iCloud Keychain, behind a developer flag. You can find information about iCloud Keychain online.)

Can you say more about device-key extension?

Would you imagine those keys expiring regularly (monthly or weekly, etc)?

(Noting, again, that I can only speak about Google's potential implementation of this.)

We do not have a firm opinion on expiration of these keys. At one end, one could think of them like cookies and thus reset them whenever cookies for that domain would be removed. But they are a lot higher friction than cookies since WebAuthn credentials require biometric confirmation (at least with Google's current platform authenticators). So perhaps they are more like saved passwords, which persist. It seems likely that management UI would allow them to be reset, but there is not yet a firm answer on whether that would also happen automatically if Google were to launch support.

how much damage could still be done if credentials were leaked before they expire? And are there other ways to protect users in this scenario?

We can consider a WebAuthn credential, in this model, to consist of either one or two private keys. The primary private key cannot be hardware bound since it is synced. The, optional, second private key (the device-bound key) hopefully would be hardware bound on a particular device. Thus the greatest risk is to the primary private key and the obvious way for an attacker to obtain them would be to impersonate the victim to their sync provider and know the victim's PIN/pattern.

The consequences of this are similar to when using a password manager: pretty bad. The attacker would have the user's credentials. Sites opting to additionally use a device-bound key would notice that a new device is being used but the protection afforded by this is up to the site. Similar to obtaining the complete set of a user's passwords, the remediation would be to rotate registered credentials on all sites.

User-agents may be able to aid in doing this should it be needed.

[plinss]

I was imagining a mechanism where a hardware based key could be used to sign synchronized keys (and the web site would rely on being presented with any key signed by the hardware key, basically using the hardware key like CAs do their root keypair but using an intermediate key on a daily basis). This would allow the synchronized keys to expire rapidly and be regenerated offline by using the hardware key and any of the synchronized keystores.

Your response indicated that's not how the device-key extension works. Can you explain more about what device-key extension is meant to be used for then? And have you considered a design like I mentioned?

[agl]

Your response indicated that's not how the device-key extension works. Can you explain more about what device-key extension is meant to be used for then?

The device public-key extension proposes that a WebAuthn credential may have a set of secondary private keys associated with it. When registering or asserting with a WebAuthn credential, if the website requests it, an authenticator may return a public-key and signature from one of these private keys in addition to the signature from the primary private key for the credential. The idea being that if the authenticator is syncing the primary private key onto different physical devices, each physical device can create its own device-bound key for each credential. The device public-key extension thus discloses some information about the set of devices in use to aid with risk decisions.

We do not envision that most websites would use this. But, for some sites that take a risk-based approach to sign-in, this additional signal may be useful. For example, a sign-in attempt coming from a geographical location that is unusual for the account might be rendered less suspicious given proof that a known device for that user is making the request.

[torgo]

Hi @agl - what makes you think that most websites would [not] use this? Also have you discussed the idea about ephemeral synced keys that are signed by a hardware based key as Peter described? Was that design considered?

[hadleybeeman]

Thanks for the thorough and thoughtful reply, @agl.

While we appreciate that you aren't keen for the spec to list mitigations or privacy protections on the part of the credential sync fabric providers — which we understand — it is useful to brainstorm them. You, as a working group, will have put more thought and energy into threat modelling than anyone else at this point. It's valuable to capture that.

We'd recommend that you include something in the spec, when you get to drafting it, to share some of this thinking with implementers (even something as simple as "users are trusting credential sync fabric providers to keep their keys secure. While the mechanisms of demonstrating that trust or keeping those credentials secure is out of scope for this spec, we are flagging to implementers that they may need to focus on this problem. Without it, the entire feature won't work.").

While the implementers may choose to address the issue in different ways, it's still helpful to give them that warning/benefit of your advanced thinking.

[agl]

what makes you think that most websites would [not] use this?

Most sites use a model based on username+password and let people reset passwords with an emailed link. For such sites the device-bound keys are complexity they don't need.

Sites that already have step-up challenges such as SMS OTP when signing in on a new device are those that I think would use the signals that device-bound keys provide.

Also have you discussed the idea about ephemeral synced keys that are signed by a hardware based key as Peter described? Was that design considered?

I don't feel that I understand the proposal enough to comment. An important part of the device-bound keys is that they sign a nonce from the site, proving active possession. Having them sign a synced credential provides very different security properties. I'm also unsure how new devices work in such a scheme.

We'd recommend that you include something in the spec, when you get to drafting it, to share some of this thinking with implementers (even something as simple as "users are trusting credential sync fabric providers to keep their keys secure. While the mechanisms of demonstrating that trust or keeping those credentials secure is out of scope for this spec, we are flagging to implementers that they may need to focus on this problem. Without it, the entire feature won't work.").

Understood. Thanks for the guidance. I can't speak for the whole working group, but I can write pull requests along those lines and hopefully that's enough!

[plinss]

I don't feel that I understand the proposal enough to comment. An important part of the device-bound keys is that they sign a nonce from the site, proving active possession. Having them sign a synced credential provides very different security properties. I'm also unsure how new devices work in such a scheme.

Happy to explain better: this stemmed from a concern about synced keys getting leaked.

My thinking was that the user could have a device-bound key which is used to sign the public key of an ephemeral key pair that gets synced. When registering with a site, the device-bound key would be required to be present (to sign a site-specific ephemeral key that's generated on the fly), and the site would learn the public key of the device-bound key.

However during normal usage, the site would accept a signed nonce from a key that is itself signed by the device-bound key, so the device-bound key need not be present. The model here is how CA's use an intermediate key to sign certificate requests, keeping their root key securely offline (or DNSSEC using zone-signing keys and key-signing keys).

The advantage is that the synced keys could be set to expire frequently. Upon key expiration, the device-bound key would have to be presented to one of the devices that can sync the ephemeral keys and it regenerates all the ephemeral keys that need it. This operation can be done offline. This way should a synced keystore get leaked, the damage is at least limited in time somewhat (presuming the newly generated keys aren't immediately leaked, of course).

This would be an additional mode to requiring direct use of a device-bound key or allowing completely software keys. It's a hybrid approach, somewhat between the two in security while presenting less of a burden on the user than a straight device-bound key, while ensuring that the user at least had access to the device-bound key relatively recently.

[equalsJeffH]

wrt #686 (comment) (above)

We'd recommend that you include something in the spec ... [e.g.] ... as simple as "users are trusting credential sync fabric providers..."

Understood. Thanks for the guidance. ...

fyi, this is noted here in webauthn issue #1665 "Synced Credentials"

[hadleybeeman]

Thanks, @agl and @equalsJeffH. That sounds like a good way forward on the concerns I mentioned.

On that basis, we're happy to close this issue and wish you well with this. Do come back if we can help with anything further.

[agl]

Sorry, there's something wrong with my GitHub notification emails and I missed a prior update:

My thinking was that the user could have a device-bound key which is used to sign the public key of an ephemeral key pair that gets synced. When registering with a site, the device-bound key would be required to be present (to sign a site-specific ephemeral key that's generated on the fly), and the site would learn the public key of the device-bound key.

However during normal usage, the site would accept a signed nonce from a key that is itself signed by the device-bound key, so the device-bound key need not be present. The model here is how CA's use an intermediate key to sign certificate requests, keeping their root key securely offline (or DNSSEC using zone-signing keys and key-signing keys).

I think the difference here is that the device-bound key wouldn't be involved in "normal usage". We believe that, for the majority of sites, a synced WebAuthn credential has good advantages over a password. But we hear from some sites that they really want a device-bound key as an additional signal. However, if the device-bound key simply signed a synced key then, at sign-in time, there's no difference between a known device signing in, an a leaked synced key being used with a replayed signature by a device-bound key.

In order to prevent replays, you would want the signature by the device-bound key to also sign over a nonce—proving that it was exercised for each sign-in request. At which point you have a something very similar to the current proposal.