Timeline for Will sky fall if I don't verify `AuthenticatorAttestationResponse`?
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 28, 2024 at 20:40 | comment | added | Emil Lundberg | Also, you do always need to send clientDataJSON to the server to verify both an attestation signature (which is not always relevant) and an authentication signature (which you absolutely always must, as outlined in the answer). The client may add properties to the clientDataJSON that the server does not know, so the server cannot reliably reconstruct clientDataJSON on its own. But you do need to validate in particular that the challenge and origin properties have the correct values. | |
| Feb 28, 2024 at 20:35 | comment | added | Emil Lundberg | Most of this is true only for authentication signatures. The attestation signature is not even made with the credential private key, but with the authenticator vendor's attestation key (unless it's a self attestation, but that's mostly useless anyway). The value of the attestation signature is to prove the make and model of the authenticator; if you (the server) are not interested in that, you do not need to verify the attestation signature. In fact WebAuthn issue #1710 tracks an initiative to make attestation verification more clearly optional. | |
| Feb 28, 2024 at 4:51 | comment | added | DannyNiu | I've found this section from the WebAuthn spec (I specifically used an older version in case of link rot). Can you make refutation? | |
| Feb 28, 2024 at 4:15 | comment | added | DannyNiu | Some problems I'm seeing: (1) verificationData is only used in "FIDO U2F Attestation Statement Format". (2) Registeration is a sort of "trust-on-first-use" thing, so if an account is registered with a public key, CSRF cannot associate a different public key with the account without a 2nd factor. (3) even if an attacker manage to register "user's actual public key" on a phishing site, the client/authenticator won't produce a signature that can be verified with that public key, because that phishing site's "origin" is different, so a different key pair is used. Can you explain? | |
| Feb 28, 2024 at 4:13 | history | edited | CBHacking | CC BY-SA 4.0 | added 833 characters in body |
| Feb 27, 2024 at 15:15 | history | edited | CBHacking | CC BY-SA 4.0 | added 15 characters in body |
| Feb 27, 2024 at 15:10 | history | answered | CBHacking | CC BY-SA 4.0 |