Detached FIDO Authentication

[Dennis Kniep]

Hi FIDO-Community,

we developed "Detached FIDO Authentication" for applications without WebAuthn support. 

https://denniskniep.github.io/posts/01-detached-fido-authentication/

Only if we enforce FIDO-only and block legacy authentication via SMS, Call, TOTP, Push etc. we are truly phishing-resistant.

WebAuthn is a requirement, but not always available. Some legacy Apps use WebViews without WebAuthn support.

"Detached FIDO Authentication" is our answer until applications support WebAuthn.

We are looking forward to your feedback and hopefully improvement ideas.

[Emil Lundberg]

Hi Dennis,

I have a question: You state that "This “same device” check prevents phishing of the WebAuthn-incompatible WebView portion of the process.", but how does the "same device" check prevent this? If the page loaded in the legacy WebView is a phishing site, won't any remote requests done by it originate from the user's same client device as the remote requests in the WebAuthn-compatible browser? So in that case both the privateToken and any authentication cookies will be returned to the legacy WebView even though it's running malicious code.

Is it perhaps that if the cookies are set to HttpOnly they won't be accessible to any client-side JavaScript relaying credentials, so the request would have to originate from either a different host or a compromised browser in order to intercept the cookies? If so, I think it's worth highlighting HttpOnly in your proposal.

Emil Lundberg

Software Engineer | Yubico

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/52e4019a-0043-4660-98db-980f326bf1d3n%40fidoalliance.org.

[Dennis Kniep]

Hi,

if we look at the phishing technique where the phishing website is hosted under a different Domain and all requests are proxied through a “man-in-the-middle" phishing proxy to the original website. 
Then the requests from the “man-in-the-middle" phishing proxy to the webserver and the requests from the Browser to the webserver have different IPs. 
The important part is that the requests from the Browser can not be intercepted by an “man-in-the-middle" phishing proxy, because we are authenticating with FIDO.
(see diagrams in attachment) I'am going to update the blog post with this diagrams for clarification.

The attack vector you are referring to with "WebView is running malicious code" is XSS?

Cheers,
Dennis

[Emil Lundberg]

What I mean is that even without XSS, if a user falls victim to a phishing attack they'll have loaded a phishing page under the attacker's control. The scenario is that the attacker is in control of JavaScript running in the victim's non-FIDO browser, but not in control of the browser itself.

In this case the attacker's phishing webpage, and any script it serves, will be loaded and running in the non-FIDO WebView on the victim's client device, so any requests originating from that page will originate from the victim's IP address (1.2.3.4 in your examples), not from the phishing server's address (6.6.6.6). So if the phishing page uses AJAX requests to interact with the IDP, it'll bypass the IP address validation, and the IDP will return any secrets and cookies to the phishing page. If those secrets and cookies are accessible to the attacker's JavaScript, the attacker can intercept them without routing the requests through a proxy server. Thus the attacker can initiate the detached FIDO flow and receive the privateToken, call out to the FIDO Browser which will correctly complete the FIDO authentication, and then use the compromised privateToken to redeem a session secret. It doesn't matter if the authentication in the FIDO browser is secure if the phishing page in the non-FIDO browser can still acquire a session secret, or indeed other sensitive data, in the end.

On further thought, I don't think HttpOnly cookies is enough. I think HttpOnly should suffice to secure the initial session cookie, but the session cookie is far from the only sensitive piece. While the attacker won't have direct access to the session cookie, they can still exercise the cookie in AJAX requests to access and exfiltrate sensitive data. Furthermore we should assume the attacker has the victim's password, since they're on a phishing page. They can also use AJAX to enroll new WebAuthn credentials under the attacker's control - not by calling the WebAuthn API in the browser of course, but by simply constructing the PublicKeyCredential structures in pure JavaScript (or, if the server requires trusted attestation, by calling out to a remote server with an approved authenticator connected). Then the attacker can access the account directly from any other device, since they now have full control of the password and a FIDO credential registered to the account.

Did I miss something that would prevent these kinds of attack?

Emil Lundberg

Software Engineer | Yubico

[Dennis Kniep]

I think its not possible for the phishing page to use AJAX requests to interact with the IDP. Because the phishing page is hosted on a different domain than the IDP. 
The CORS Policy of the Browser will prevent such Ajax requests (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)
The CORS Policy will identify the IDP as cross-origin resource. Therefore all AJAX requests from the phishing page to the IDP will be denied.
 
Example error in Chrome:
Access to XMLHttpRequest at 'https://microsoft.com/' from origin 'https://www.google.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.


I hope I have understood your concerns correctly? 

Cheers,
Dennis

[Emil Lundberg]

Ah right, of course, that's what I forgot. Thanks!

Emil Lundberg

Software Engineer | Yubico