Firefox on Windows 10 always includes attestation statements even if the attestation field is set to none.
Categories
(Core :: DOM: Web Authentication, defect, P3)
Tracking
()
People
(Reporter: jcj, Unassigned)
References
()
Details
Reported at WebAuthn WG:
Firefox on Windows 10 (unlike Chrome or Edge) seems to always include attestation statements even if the attestation field is set to none.
|
||
Comment 1•4 years ago
|
||
Which Windows 10 version is this?
Hi J.C Jones,
Are you still able to reproduce this issue? If that is the case, please confirm Comment 1 , and please, add further details such as in which versions are you experiencing the issue, and also more detailed repro steps.
Thanks in advance,
Jerónimo.
|
Reporter | |
Comment 3•3 years ago
|
||
I am not in a good position to acquire such information as of now, and won’t be able to for quite some time.
Hi,
thanks for your quick response. I close this issue as 'Resolved-Incomplete'. Please, feel free to reopen it if you experience the same issue again.
Regards,
Jerónimo.
Hello,
I am testing Yubikey securitykey with Firefox 90.0.2 version on Windows 10. In the navigator.credentials.create() API, I am providing the attestation value as "none" . But the response from this API returns the fmt attribute of the attestationobject as "fmt": "packet" which was supposed to be "none". Could anyone let me know if am missing any information.
The same use case when tested on MAC + Firefox + Security key return the attestationobject as "fmt": "none" which is expected.
Thanks in advance!
Shiny
|
||
Comment 7•3 years ago
|
||
I also encounter this issue in the latest Firefox version (91.0.1) on Windows 10 (21H1). Using a TrustKey G310H I tested WebAuthn using https://webauthn.io/ and set attestation to "none".
I use the Firefox integrated web developer tools to sniff the HTTP requests/response and responses and was able to see the following
attestationObject:
o2NmbXRmcGFja2VkZ2F0dFN0bXSjY2FsZyZjc2lnWEgwRgIhAKNATbN0L7QytVs9vSNEzs4lzvW9iMcXJkdu_RK6PT_RAiEAqAAlt2z5xOBoigwOm-ZZBs574X4S76u2NijHrM_i75NjeDVjgVkCuDCCArQwggJZoAMCAQICCQC8XjO4t4aUKDAKBggqhkjOPQQDAjCBrzELMAkGA1UEBhMCS1IxETAPBgNVBAgMCFNlb3VsLVNpMRMwEQYDVQQHDApHYW5nbmFtLUd1MRcwFQYDVQQKDA5lV0JNIENvLiwgTHRkLjEiMCAGA1UECwwZQXV0aGVudGljYXRvciBBdHRlc3RhdGlvbjEcMBoGA1UEAwwTZVdCTSBDQSBDZXJ0aWZpY2F0ZTEdMBsGCSqGSIb3DQEJARYOaW5mb0BlLXdibS5jb20wHhcNMTkwNTAzMDYyNjEzWhcNMjkwNDI5MDYyNjEzWjCBsTELMAkGA1UEBhMCS1IxETAPBgNVBAgMCFNlb3VsLVNpMRMwEQYDVQQHDApHYW5nbmFtLUd1MRcwFQYDVQQKDA5lV0JNIENvLiwgTHRkLjEiMCAGA1UECwwZQXV0aGVudGljYXRvciBBdHRlc3RhdGlvbjEfMB0GA1UEAwwWZVdCTSBGSURPMiBDZXJ0aWZpY2F0ZTEcMBoGCSqGSIb3DQEJARYNaW5mb0Bld2JtLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABAVN5las9Uq_YE9bBDsGp8nmimt7IhLzb2eb_ki3vR3Os7C4Zjj_RXBTNEN59KtUuZjM9CAr2UyMKD1FwWGwPQCjWjBYMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUtyf38YgL9toq3QbPfEjg4Re5FP4wHQYDVR0OBBYEFEQuqVonVjHARnNctCAI2nncYGJxMAsGA1UdDwQEAwIF4DAKBggqhkjOPQQDAgNJADBGAiEAoE2KQ3uGe-Fq26U59E4Ls0lDNiIzEYEcRfDUp4Z2wCICIQDebEl4fZGEe92N-kUlfI_DPpyVu2ijoUakz2fe1X4gsmhhdXRoRGF0YVkBRHSm6pITyZwvdLIkkrMgz0AmKpTBqVCgOX8pJQtghB7wRQAAAMWVRCsu8V5N77Jw77EG-stOAMAz0bHQGOEUHD0hnm5RqmiWn39AuS7lgP69hDD8RtY1P0KVqHCfAdzgATzIjnyOv5N05E0zcksBI6XV5EP2eccmEpVvqNEfb4CO_Zz0XxKeXXSSWJs-ceiHEiF_J0p8B_4jvq5lKEFBGnOiKQAWUmWq93k_-u-FmOasYu9xkPz1rfG7KfWU2IsAwrkZ9dsTsRbBPS3gd1AddpVjEQewmp4GuMzGeRhBnATeljA3Pq-APiiDg0ozolb8OBRX-A1R9e-lAQIDJiABIVggkV2wF0q0jrTiXRlV7Q5CP_yD0rLI67PPsB2FmQUu0mciWCBicsJXrpHT0l8fFdg99ROCFvFuUpvhwXStScXaA33A-Q
If I decode it I can see that it includes the AAGUID of my device: 95442b2ef15e4defb270efb106facb4e which decodes to 95442b2e-f15e-4def-b270-efb106facb4e which is the AAGUID if my G310H as documented by TrustKey. I have not checked the other parts of the presented data, but I assume they contain a full attestation response.
This is a serious privacy issue as the AAGUID should not be available to the replaying party in case the attestation type " none" is selected.
If I do the same in Chrome I only get an AAGUID of zeros.
Description
•