- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Oct 2018 11:14:13 +0000
- To: public-webauthn@w3.org
@equalsJeffH Yes, I agree with your assessment. Assuming TLS is used, and correctly, a discrete MitM is an unlikely scenario; what I was considering is mainly the MitB case, by the RP inadvertently including malicious script (whether via XSS or explicitly loading script from another domain) on their page for example. I would like to mention something like Content Security Policy, and perhaps Token Binding, as an example protection instead of just "TLS and related technologies", but I'm not sure which of these technologies are applicable and mature. Ah, yes, you're right that in the general case the attacker does need to replace most of the `PublicKeyCredential` object. The attacker doesn't need to change the `clientDataJSON`, but would have to be able to control the generated credential ID in order for the signed `attestationObject.authData.attestedCredentialData.credentialId` to agree with the `PublicKeyCredential.rawId`. This can be done with Self and None attestation but not if the attestation object needs to be recognized as a genuine attestation from a trusted authenticator vendor, since that would require using a genuine authenticator device that would generate the credential ID internally. -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1088#issuecomment-428533488 using your GitHub account
Received on Wednesday, 10 October 2018 11:14:22 UTC