Re: [webauthn] Leap of Faith not only for Self and None Attestation Types

hm, if I understand correctly, there's various nuances to the overall man-in-the-middle (MITM) class of attacks and how webauthn defends against them than the [original post](https://github.com/w3c/webauthn/issues/1088#issue-364977414) (OP) assumes/discusses:
> Lets assume that there is a man-in-the-middle (MiM) who owns the same authenticator as the user or any authenticator that is accepted by the Relying Party.  

If the above imagines that the attacker places a discrete MITM system between the user's system and the RP's server, it seems to me that it will be detectable by RPs who properly perform verification at the TLS layer and up. Caveat: the attacker must have managed to have a trusted CA mis-issue an impostor TLS cert for the RP (the discrete MITM system will need to terminate the RP <--> ATKR  and ATKR <--> USER  TLS connections).  

In this situation, without such an impostor cert the user likely will be presented with a "dangerous connection" interstitial page, and if HSTS policy has been by the RP (or established via pre-loading), the user will have no click-through recourse (if HSTS is faithfully implemented by the user agent).

Even with such an impostor cert, if the user already has interacted with the RP in the past, and established a [TLS Token Binding ID,](https://tools.ietf.org/html/rfc8473) say, which is used by the RP to (for example) bind any of the RP's cookies set on the user's browser, then the MITM is detectable by the RP (of course the RP needs to carefully validate everything on their end of the connection in order to detect such malfeasance). 

> During Registration the MiM replaces the attestationObject, that had been generated by the users authenticator, with the attestationObject, that had been generated by the attackers authenticator using the mentioned device. 

Actually, AFAICT, the MITM (aka MiM) will need to replace the entire returned [PublicKeyCredential](https://w3c.github.io/webauthn/#publickeycredential) object rather than only the [attestation object](https://w3c.github.io/webauthn/#attestation-object) because [PublicKeyCredential](https://w3c.github.io/webauthn/#publickeycredential).[response ](https://w3c.github.io/webauthn/#dom-publickeycredential-response) conveys the [clientDataJSON ](https://w3c.github.io/webauthn/#dom-authenticatorresponse-clientdatajson) separate from the [attestationObject](https://w3c.github.io/webauthn/#dom-authenticatorattestationresponse-attestationobject) and the clientDataJSON is needed to validate the signature within the [attestationObject](https://w3c.github.io/webauthn/#dom-authenticatorattestationresponse-attestationobject) [1].


> The Relying Party can not detect the attack.

Well, it seems, IIUC, that the RP can detect things as discussed above when the attacker is embodied as a discrete MITM system between the user's system and the RP's server, no?

However, if the attacker is embodied as a man-in-the-browser (MITB), then I tend to agree that providing assurances are tough, because the TLS protections are essentially obviated -- but it depends on the attacker getting everything exactly correct, continuously MITB'g subsequent authn ceremonies, and there not being any browser characteristics alterations the RP might detect.  

Probably there's many more fine details to tease apart here, though to what level of detail we ought to go in the spec is a good question. I have some modest comments on the pull request I'll try to write up tomorrow. 

HTH

###
[1] tho the attacker may be able to get by with only replacing the [PublicKeyCredential](https://w3c.github.io/webauthn/#publickeycredential).[response](https://w3c.github.io/webauthn/#dom-publickeycredential-response) value (unless the RP is validating that  `PublicKeyCredential.rawId` is the same as `attestationObject.authData.attestedCredentialData.credentialId`) and/or the RP is doing something with those two values such that not having them be equivalent will break things and throw errors. 







-- 
GitHub Notification of comment by equalsJeffH
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1088#issuecomment-428440137 using your GitHub account

Received on Wednesday, 10 October 2018 05:12:13 UTC