Re: [webauthn] Why not make things simple? (#1709)

@dagnelies Yes, you are correct that without a signature during registration, the response can be freely tampered with. However, that is still mostly true even with attestation, because that's not a problem attestation is meant to solve. Copying [my response](https://github.com/w3c/webauthn/issues/1710#issuecomment-1082187565) from #1710 for the benefit of other readers:

> Yeah, the critical piece to realize is that all WebAuthn credentials are "trust on first use" (TOFU) keys. Even with attestation, it is indeed possible for a malicious script to replace the public key and attestation statement during registration, and thus have the attacker's key registered instead of the victim's key. We touch on this in [13.4.4. Attestation Limitations](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#sctn-attestation-limitations) in the Security Considerations section.
> 
> What attestation does is provide a way for the authenticator to prove to the RP what _kind_ of authenticator it is. That proof could eliminate the possibility of software-generated malicious keys, but a malicious script could still in theory call out to a remote server to generate an attestation statement using a genuine authenticator on the RP's allow list. At best the RP could display a name and/or image of the authenticator as identified by the attestation statement, which could allow attentive users to notice if there's a discrepancy. But even then the attacker's remote server could have an array of authenticators of different brands and models to account for that too. And of course, [self attestation](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#self-attestation) is always susceptible to tampering since by definition there's no way to link the attestation key to any established root of trust.
> 
> So yeah, the registration ceremony is a [leap of faith](https://datatracker.ietf.org/doc/html/rfc4949#page-182), with or without attestation. But assuming one was completed securely, any subsequent authentication ceremonies are highly resistant to tampering since at that point there is an established trust relationship with a particular credential public key. You cannot know with certainty who the public key came from during registration, but you can know with certainty that an authentication signature came from _the same_ key pair as was registered.

As for your last remark:

> Providing a `signature` field like in `credentials.get` would have been nice.

Without previous knowledge of the public key for that signature, the signature will not prevent tampering - it will at most prevent accidental data corruption. The registration ceremony is similar to a "key signing party": you have no previous trust relationship with the user, so any signature they could give you at that point is meaningless, but once you have their public key you can securely authenticate them after that. The attestation signature just gives you more things you can assume (like whether private keys can be copied) _after_ you have established that trust relationship.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 29 March 2022 18:11:37 UTC