On Tue, Aug 30, 2022 at 1:58 AM Yifan Luo <l...@google.com> wrote: > Hey! > > I'm taking a look at this feature as a security reviewer and I'm a bit > lack of the background information of it. > > Would you mind adding some explainer/design doc for it? It would be great > if you could also fill in a security-privacy-questionnaire > <https://www.w3.org/TR/security-privacy-questionnaire/> for the feature. >
Hi there! Yea, https://github.com/w3c/webauthn/pull/1663 is getting pretty long and large. Let me try and write an explainer here (and maybe this should go in the WebAuthn set of explainers): WebAuthn today is all about hardware binding: whether you use a security key or the TPM in a laptop, the private key is created in secure hardware and never leaves. A credential is one-to-one with a physical device. (And we generally call these devices "authenticators".) But since devices break and get lost, this means that we have to tell people that they need to register a backup authenticator and both a) keep it in a fire safe at all times, and b) make sure it's registered on all the sites they use. That's a logistical problem for users, a cost problem, and a bit of a contradiction. So while WebAuthn works great in an enterprise context, where there's a helpdesk to handle the edge cases, WebAuthn is very limited in the degree to which it can be broadly used. But that's bad! Nobody likes passwords. So, across multiple platforms, we're building "passkeys". These are WebAuthn credentials that are synced and which can be restored after device loss. If you install the iOS 16 beta today, it'll create WebAuthn credentials that are saved in iCloud Keychain. If you can recover the iCloud Keychain contents then you can recover the passkeys, same as recovering passwords. You can also use the phone, with Bluetooth for proximity checks, and send a signature to e.g. Chrome running on Windows—so the phone serves like a security key too. But for modern sites, sign-in is a risk-analysis question. And that risk analysis continues after sign-in and considers the actions that are being taken on the account. By syncing passkeys we've enabled their use broadly, but most of the time users will be using the same devices. The device-bound key extension tries to meet both sets of needs by adding a second signature when a synced WebAuthn credential is used. This second signature is from a device-bound key that's generated on demand when sites request it. So when a sign-in comes from an odd location (for that user) a site will be able to see that the second signature is from a device that the user has used before and be mollified. (Or perhaps it'll see no such signature and so present additional challenges.) The device-bound keys are always per-passkey, so no cross-account correlation is possible. In practice, this change in Chromium consists of the ability for sites to request this feature, which is expressed as an extension in the WebAuthn request, and the plumbing for Chromium to convey that back and forth from the authenticator. Apart from the Web API fields in the request, everything is encoded in the CTAP2-subset of CBOR (as is standard in WebAuthn). Chromium will end up parsing this from the authenticators that the user chooses to use, but they are known to be physically proximal and Chromium is already parsing CBOR from such authenticators. Cheers AGL -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL9PXLwYWEBQZVYPq4ov4EZ%2BSAxbhQG%2B5%3DQ-cy3P8GX6%3DpVr_w%40mail.gmail.com.
