webauthn
webauthn copied to clipboard
w3c
Spec abstract is out of date on the eve of multi-device credentials and cross-device auth
This sentence in the spec's abstract is now out of date with the upcoming launch of multi-device credentials across all three major platform vendors:
Conceptually, one or more public key credentials, each scoped to a given WebAuthn Relying Party, are created by and bound to authenticators as requested by the web application.
This needs to be updated to reflect the reality that A) backup of credentials mean credentials are no longer device-bound, and B) capabilities like Apple's shareable multi-device credentials means credentials are potentially no longer user-bound either.
I learned about this thanks to your post, and I must admit that the concept of sharing private keys in the "cloud" does not sound like the epitome of security to me. If some day in the future this central credentials storage gets leaked/breached/hacked/eavesdropped/whatever, it would be a disaster. I'm pretty sure there are all kind of security measures in place, but it wouldn't be the first time something like this happens.
Until now, the private key being bound to the device gave me a certain sense of security. Not anymore though with "synced-in-the-cloud-secrets" aka multi-device credentials. It makes the whole reasoning also a bit more difficult.
In this light, I think too it is crucial to update the abstract of this specification to highlight that these "private keys" are not device-bound anymore, but can be synced/shared. The concept is fundamentally altered because of this, with implications for usage, security and privacy.
Lot of documentation here will calm you, @dagnelies
Until now, the private key being bound to the device gave me a certain sense of security. Not anymore though with "synced-in-the-cloud-secrets" aka multi-device credentials. It makes the whole reasoning also a bit more difficult.
In this light, I think too it is crucial to update the abstract of this specification to highlight that these "private keys" are not device-bound anymore, but can be synced/shared. The concept is fundamentally altered because of this, with implications for usage, security and privacy.
"Passkeys in the Google Password Manager On Android, the Google Password Manager provides backup and sync of passkeys. This means that if a user sets up two Android devices with the same Google Account, passkeys created on one device are available on the other. This applies both to the case where a user has multiple devices simultaneously, for example a phone and a tablet, and the more common case where a user upgrades e.g. from an old Android phone to a new one." https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html#:~:text=synchronization%20and%20backup.-,Passkeys%20in%20the%20Google%20Password%20Manager,e.g.%20from%20an%20old%20Android%20phone%20to%20a%20new%20one.,-Passkeys%20in%20the
Reviewing this issue, I suspect the Abstract has been fine all along. The word "authenticators" links to here...
https://www.w3.org/TR/webauthn-2/#authenticator
Which states the following (emphasis mine):
A cryptographic entity, existing in hardware or software, that can register a user with a given Relying Party and later assert possession of the registered public key credential, and optionally verify the user, when requested by the Relying Party. Authenticators can report information regarding their type and security characteristics via attestation during registration.
A WebAuthn Authenticator could be a roaming authenticator, a dedicated hardware subsystem integrated into the client device, or a software component of the client or client device.
Re-reading this issue with the benefit of time, I'm understanding that the abstract, multi-device "authenticators" created by way of passkeys synchronization still fits this definition of "authenticator". And in fact this definition hasn't changed at all in the last four years so it's probably been fine all along.
I'm going to close this out for now. We can re-open if others believe the abstract still needs to be updated.
I'm second-guessing myself a bit because being able to "clone" credentials across authenticators vis-a-vis airdropping credentials between iCloud accounts seems to conflict with even the authenticator abstraction model.
Reopening this to review the current definition of Authenticator in the spec and update it to reflect the current times. @nicksteele will take on that task.
WAWG Meeting @ Aug 30: PR #1931 addressed part of my original issue, but I think there's more work needed to properly update the spec's Abstract. @timcappalli and I will work to try and collect "outdated content" issues like this and address them in one fell swoop.
Issue can be closed, can open a new issue that captures the untouched parts of @MasterKale's original issue
