If you're logged into a Google Apps domain it will change the google.com to match your domain. If you're logged into a regular Google account it will remain as google.com.
1) Online service challenges the user to login with a previously registered device that matches the service's acceptance policy.
2) User unlocks the FIDO authenticator using the same method as at Registration time.
3) Device uses the user's account identifier provided by the service to select the correct key and sign the service's challenge.
4) Client device sends the signed challenge back to the service, which verifies it with the stored public key and logs in the user.
What's to stop an attacker from putting up a phishing page like this, MITM the username/password, forwarding the service's challenge back to the end-user?
I'm going to guess the trick is that the end-user browser has some way to know where the signed challenge should be POSTed for a given service, e.g. by baking that into the "account identifier" used in Step 3. So an attacker can try to MITM the account identifier, but the signed challenge would always be sent directly to the service bypassing the attacker. I'll have to check out the spec...
OK, just following up on my own curiosity here. Sorry if this is getting OT...
Every FIDO request has an AppID which is the service you are registering for, and it's an HTTPS URI.
When you resolve (HTTPS GET) the AppID, it returns a list of "FacetIDs" which are basically the different channels/endpoints which you can trust sending an authentication response. No more than one of those channels may be a 'Web Origin' facet. "In the Web case, the facetID is the Web Origin [RFC6454] of the web page triggering the FIDO operation". Examples of a non-web facets are "android:apk-key-hash:2jmj..." or "ios:bundle-id:com.acme.app"
While processing an authentication request, the FIDO client must;
o Obtain FacetID of the requesting Application. Resolve AppID URI and make sure that this FacetID is listed in TrustedApps.
- If FacetID is not in TrustedApps – reject the operation
The FIDO client will embed the FacetID it used as part of the signed response it sends back to the server.
The authentication response can optionally contain TLS channel binding information, which the server can use to try to detect MITM (although there can be false positives depending on your network). It also looks like a MITM may be able to use a specially crafted certificate to ensure channel binding information is not usable by the FIDO client.
The final step on the FIDO client in the spec is simply: "Send [xyz]Response message to FIDO Server".
So in summary, it looks like the response channel can be DYNAMIC -- I can ask your FIDO Client to send an authentication response from a different URL than the one you used when you enrolled, but the domain I ask from has to be listed in the response provided by HTTPS GET of the AppID.
The haven't found where spec says exactly how the facet ID should be matched up against the string array returned by resolving the AppID. It appears the full path is undefined and left to the control of the attacker. So a FacetID of https://www.google.com would allow an authentication response to be sent to https://www.google.com/a/domain.com/...
Non-phishable two-factor auth token: http://fidoalliance.org/
See presentation: https://docs.google.com/a/google.com/presentation/d/16mB3Npt...