Re: [webauthn] Add privacy consideration about terminating getAssertion early

I believe with hot-plugging `makeCredential` doesn't have the same information leak anymore, and either way this PR made the same normative changes to both the `makeCredential` and the `getAssertion` algorithms. But you're right that the Privacy Considerations subsection only mentions `getAssertion`, which should be fixed.

My reasoning is the following. The attack would previously be:

1. The attacker calls `makeCredential` with some credentials in the `excludeCredentials` parameter.
2. The browser notices that one of the excluded parameters is available, and terminates the operation immediately.
3. The attacker concludes that the user possesses one of the named credentials.

Whereas now, if an excluded credential is available, the browser will simply ignore that authenticator and instead wait for a new authenticator without an excluded credential to appear. If the browser were to violate the spec and return a `NotAllowedError` as soon as the user denies the prompt (which step 21 now expressly forbids), the attack would be:

1. The attacker calls `makeCredential` with some credentials in the `excludeCredentials` parameter.
2. The browser notices that one of the excluded parameters is available, ignores that authenticator and waits for another to appear.
3. The user plugs in a new authenticator.
4. The browser asks the user if they want to create a credential on that authenticator.
5. The user denies the prompt.
6. The browser returns a `NotAllowedError` to the attacker.
7. The attacker notices that a `NotAllowedError` was returned before the timer expired.
    - The attacker **can** conclude that the user has an authenticator that does not contain one of the named credentials.
    - The attacker **cannot** conclude that the user has an authenticator that contains one of the named credentials.
    - The attacker **cannot** conclude that the user does not have an authenticator that contains one of the named credentials.

I suppose this conclusion could perhaps be combined with some external assumptions (like an upper limit on how many authenticators a user is likely to own) to narrow the field to some extent, possibly enough to identify a single user. But again, this should also not be possible if the browser never returns the `NotAllowedError` before the timer expires.

Please let me know if you spot any errors in the above reasoning. :)

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/687#issuecomment-359087435 using your GitHub account

Received on Friday, 19 January 2018 20:59:44 UTC