- From: =JeffH via GitHub <sysbot+gh@w3.org>
- Date: Fri, 19 Jan 2018 23:03:43 +0000
- To: public-webauthn@w3.org
**_Thanks_** @emlun for your [detailed analysis above](https://github.com/w3c/webauthn/pull/687#issuecomment-359087435). I had not reviewed [the diff](https://github.com/w3c/webauthn/pull/687/files) closely enough and had focused on the added [Authentication Ceremonies privacy considerations](https://w3c.github.io/webauthn/#sec-assertion-privacy) subsection rather than the revised lifetime timer stipulations in _**both**_ [#createCredential](https://w3c.github.io/webauthn/#createCredential) aka `[[Create]]` **_and_** [#getAssertion](https://w3c.github.io/webauthn/#getAssertion) aka `[[DiscoverFromExternalSource]]`. For [#createCredential](https://w3c.github.io/webauthn/#createCredential) aka `[[Create]]` these are steps 20 and 21. mea culpa! I agree with the overall conclusion of the [detailed analysis above](https://github.com/w3c/webauthn/pull/687#issuecomment-359087435): a malicious RP (aka "the attacker") will not learn anything through seeding of the [`excludeCredentials` list](https://w3c.github.io/webauthn/#dom-makepublickeycredentialoptions-excludecredentials) because any returned `NotAllowedError`s are returned after the `lifetimeTimer` has expired, regardless of the user's actions (see step 21). It seems, IIUC, there are a couple details-level issues with the steps in the [detailed analysis above](https://github.com/w3c/webauthn/pull/687#issuecomment-359087435), but they do not AFAICT affect this conclusion. Here they are for completeness' sake: > 2. The browser notices that one of the excluded parameters is available, ignores that authenticator and waits for another to appear. AFAICT, the browser/client-platform does not do this (see [#createCredential](https://w3c.github.io/webauthn/#createCredential) steps 19.5 and 19.6), rather the authnr does this (see [authenticatorMakeCredential](https://w3c.github.io/webauthn/#op-make-cred) step 3), and returns `NotAllowedError`, which is handled by [#createCredential](https://w3c.github.io/webauthn/#createCredential) step 20 switch branch "If any authenticator returns an error status". > 4. The browser asks the user if they want to create a credential on that authenticator. nit: AFAICT the spec does not stipulate whether the browser, client platform, or authenticator prompts the user. > 6. The browser returns a `NotAllowedError` to the attacker. > 7. The attacker notices that a `NotAllowedError` was returned before the timer expired. Ah, but the imperative "this step **MUST NOT** be executed before lifetimeTimer has expired" language this PR inserted into [#createCredential](https://w3c.github.io/webauthn/#createCredential) step 21 means that the error is not returned before the timer expires, yes? (which makes the above analysis stronger). thanks again. -- GitHub Notification of comment by equalsJeffH Please view or discuss this issue at https://github.com/w3c/webauthn/pull/687#issuecomment-359114271 using your GitHub account
Received on Friday, 19 January 2018 23:04:04 UTC