W3C home > Mailing lists > Public > public-webauthn@w3.org > July 2019

Re: [webauthn] Add to sec cons a brief discussion of the sec properties accrued by authnr & client platform proximity (#1257)

From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
Date: Thu, 11 Jul 2019 13:31:22 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-510486375-1562851881-sysbot+gh@w3.org>
I don't think the main concern is spatial proximity, but rather that the communication with the authenticator must be mediated by the user's client so that it can enforce origin restrictions. The example brought up on yesterday's WG call was using network-based transports to communicate with the authenticator, much like using a mobile push notification as 2nd factor.

Consider an authentication flow like this:

1. Alice goes to log in on `example.com`.
2. `example.com` sees that Alice has 2FA enabled, and sends a push notification to Alice's mobile phone.
3. Alice's phone prompts for confirmation to log in to `example.com`, Alice confirms.
4. The phone signs the challenge in the notification and returns the signature to the server.
5. `example.com` receives the challenge signature and allows Alice to log in.

This architecture is vulnerable to phishing:

1. A phishing attack lures Alice to try to log in on `evil.com`.
2. `evil.com` uses Alice's username and password to start login on `example.com`.
3. `example.com` sees that Alice has 2FA enabled, and sends a push notification to Alice's mobile phone.
4. Alice's phone prompts for confirmation to log in to `example.com`, Alice confirms.
5. The phone signs the challenge in the notification and returns the signature to the server.
6. `example.com` receives the challenge signature and allows Alice to log in.
7. `evil.com` receives Alice's session cookie and now has control over her account.

`example.com` could thwart this attack by requiring a cookie-based secret in addition to the mobile push, but that won't work for initial sign-in with no pre-existing state. The push notification can of course include some details (e.g., geo-IP) about the client that initiated it, but the strength of WebAuthn's phishing protection is that it _doesn't_ rely on the user noticing something wrong. That protection only works if the client can tell the authenticator what domain the user is currently visiting.

I'm guessing browser extensions like Krypton can get around this during installation by setting up a long-lived session between the extension and Krypton's server, so that their server can refuse to send the push notification if initiated from anywhere else than the user's registered browser, so that the browser can enforce the origin restrictions.

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1257#issuecomment-510486375 using your GitHub account
Received on Thursday, 11 July 2019 13:31:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:59:06 UTC