fid02

Firefox has some kind of function that de-anonymizes your yubikey when you register it. This contradicts the information that is in accordance with what you're saying (and the research I've found). Why would Firefox need to de-anonymize the key if there was no way to track it in the first place?

  • de0u replied to this.

      Thank you @fid02 for your comprehensive answer.
      I think I am not affected by the firefox thing because I would use two independent installations of Firefox in this case. Anyway I use Vanadium.

      de0u Yes, I have had this link bookmarked for years. It's not detailed at all but it's from Mozilla directly.

      It's unclear what "extended information" is.

      https://support.mozilla.org/en-US/kb/privacy-web-authentication

      Web Authentication is a powerful anti-phishing technology that uses hardware authenticators and public-key cryptography to protect your accounts.

      hardware authenticator
      A sample of Web Authentication Authenticators

      Websites that support Web Authentication are showing a commitment to very high security standards by asking for additional information about your authenticator when you register.
      Should I use one authenticator for multiple accounts?

      Using an authenticator for one account is safe, but allowing a website to ask for extended information for multiple accounts using the same authenticator can permit that website to identify a link between those accounts.

      If you are concerned about having accounts linked together in this way, you should either deny extended information when prompted, or use different authenticators for the different accounts.
      This linkability is based on the authenticators, and not on your browser. If you use the same authenticator with different browsers, websites can still identify a link between multiple accounts.

      @fid02 would you care to respond to this? I'm pretty sure this contradicts what you're saying.

          gk7ncklxlts99w1
          https://support.mozilla.org/en-US/kb/privacy-web-authentication

          That text doesn't ascribe any credibility to the claim it makes. It has several glaring issues:

          • It makes a very serious claim about privacy harms – a claim that, notably, directly contradicts the explanation provided by the actual creators of the FIDO standards – without providing any evidence at all

          • It makes a reference to an unfamiliar concept without defining it: what exactly is "extended information"? How is it relevant to FIDO? If I am to "deny" access to this "extended information", how does the "prompt" for it look like? I have never seen such a prompt in my usage of FIDO across dozens of web services, nor have I heard others refer to such a prompt.

          The fact that the text is hosted on the site of an organisation that advertises user privacy in their software does not lend any confidence to the text as long as it does not refer to any evidence or detail what it's trying to say.

          If one wants to examine whether or not the FIDO standards live up to their privacy promises, I think it's more interesting to look at scientific research that cites references and provides independent analyses. In the following I paraphrase and quote from the following research paper:

          Barbosa, M., Boldyreva, A., Chen, S., Cheng, K., & Esquível, L. (2025). Revisiting the Security and Privacy of FIDO2. Cryptology ePrint Archive. URL: https://ia.cr/2025/459

          First, let's note a central pillar in the authors' concept of FIDO2 "user privacy":

          The goal of privacy is to ensure that multiple registrations involving the same token cannot be linked together, in order to avoid tracking.

          In chapter 1, the authors reference previous academic work that analyzed and supported Webauthn's user privacy protections. The paper then argues that there is currently a lack of academic analysis into the privacy promises of CTAP specifically – hence why the article exists. (The FIDO standards are comprised of both Webauthn and CTAP taken together).

          Before quoting the authors' privacy analysis of CTAP, I'll note that the paper's main purpose is to describe a theoretical attack against the privacy guarantees of CTAP 2.1; hence why the quotes below are sprinkled with summaries of this attack scenario. The authors devised this attack scenario themselves, and the paper doesn't claim that it's been exploited in practice. Moreover, they don't think it comprises a "significant" privacy risk.

          From p. 5 (my emphasis):

          We prove that, with minor protocol changes that prevent the above Diffie-Hellman (DH)
          share reuse and by enforcing no leakage of the above meta-information, the cryptographic
          design of FIDO2 indeed guarantees strong privacy properties for the user, even considering
          local network attackers. We also show that the current FIDO2 guarantees privacy, as
          long as the attacker does not observe CTAP traces where a token reuses the same DH
          share when interacting with clients to register multiple accounts. The take-away message
          from these results is that the cryptographic traces produced by CTAP do not undermine
          privacy as long as DH shares are not repeated between usages. We do not argue that the
          concrete attack scenarios where DH share reuse could be exploited to break privacy are a
          significant reason for concern. Our claim here is that our results establish the first leakage
          upper bound for CTAP (and FIDO2 as a whole): if CTAP privacy attacks contribute
          to compromise FIDO2 privacy, then it can only be due to DH share reuse.

          A slight summary of the attack scenario they argue exists (p. 23, my emphasis):

          For the above attack, we do not claim that it has significant practical implications. Nevertheless, our tests show that, when a USB token is used to register or authenticate to multiple accounts without rebooting (by remaining plugged-in and not putting the computer to sleep), the token will reuse its DH share. This can allow a malicious server (that can access the CTAP communication, e.g., via malware with low-privilege access installed on the computer [3]) to link accounts (perhaps for different servers) of the same user, especially when multiple users share the same machine (e.g., a corporate or public computer). As we will show shortly, this potential privacy leak can be easily fixed by enforcing DH shares to be always refreshed on the token.

          I want to note that both the Webauthn and CTAP specifications are continuously revised. Since that paper was published, the FIDO Alliance released an updated CTAP specification (version 2.2): https://fidoalliance.org/specs/fido-v2.2-ps-20250228/fido-client-to-authenticator-protocol-v2.2-ps-20250228.html

          I can't see that the OP realistically needs to be concerned about potential privacy leaks from their security key. Any web service or app has lots of other more trivial ways to track users across accounts, that are much more cost-effective to conduct compared to trying to break FIDO2's privacy protections.

          As a side note: The following is a draft document, but I think it provides interesting insight into the threat model of FIDO, specifically which security attacks the FIDO Alliance considers that FIDO can realistically protect against: https://fidoalliance.org/specs/common-specs/fido-security-ref-v2.1-rd-20210525.html#threat-analysis

            I don’t think Firefox is implying any sort of breaking FIDO2’s privacy protections, more a risk regarding implementation and existing features.

            More ‘info’ on Firefox’s ‘extended information’:

            webauthn.registerDirectPrompt3=%S is requesting extended information about your security key, which may affect your privacy.

            Maybe some confusion on Firefox’s side?

            However, perhaps adding to the confusion:

            Non-enterprise attestation prevents the association of multiple passkeys within an authenticator with different RPs [Relying Parties], thus safeguarding user privacy. For example, a person using a single authenticator may create a User Authentication passkey (passkey1) for RP 1 (RP1), then create a new User Authentication passkey (passkey2) for RP 2 (RP2). Even though the person is using the same physical authenticator for both RPs and using attestation, even if RP1 and RP2 collaborate, they cannot determine that passkey1 and passkey2 are from the same authenticator, therefore, they cannot determine the transactions are from the same person.

            The question about what may happen when creating multiple passkeys with the same Relying Party (twice with RP1 in this instance) does not seem to be covered in this white paper.

            This document is even more confusing for the layman I am: https://www.w3.org/TR/webauthn-2/#anonymization-ca

            In this case, the authenticator uses an Anonymization CA which dynamically generates per-credential attestation certificates such that the attestation statements presented to Relying Parties do not provide uniquely identifiable information, e.g., that might be used for tracking purposes.

            Searching for the unique word, for instance, is also interesting.

            The same explanation as the second quote above:

            A pair of malicious Relying Parties thus cannot correlate users between their systems by tracking individual authenticators.

            Of course, I’m not claiming anything, just trying to explain the confusion and fear of some.

            schweizer Yes and no. As with anything in cybersec "it depends".

            What @fid02 said is true and this is also further extended/explained in https://fidoalliance.org/fido-attestation-enhancing-trust-privacy-and-interoperability-in-passwordless-authentication/ here:

            3.2 Types of FIDO Attestation

            There are several types of FIDO attestation which differ in how the attestation statement is signed. Note that none of these attestation types except Enterprise Attestation provide information about the specific authenticator. This is to preserve user privacy.

            However one thing needs to be noted, there are cases where using authenticator that is tied to enterprise attestation can be used outside of your "expected" enterprise flow. For example if your employee decides to be authentication provider when signing in to various portals (similar as you can now with Google, Facebook, Microsoft) or and this is just my assumption as I have never toyed with software auth apps like MS auth because I refuse and use hardware keys for anything, it may also pass more info during with flow that would allow to identify you. Again, I can't say this is 100% true and for all such passkey enabled software auth apps, but one can't exclude this.

            As for Mozilla article, it only tells partial truth, and it looks like whoever wrote it , either did not fully understand how this works or did not include all the information to make the full picture. It is unclear to me what was the intention .

                0xsigsev
                Interesting. Do I get notified during enrollment that enterprise attestation is requested?
                Is enterprise attestation enabled or disabled by default when I register a hardware key for a company M365 account?

                    schweizer Do I get notified during enrollment that enterprise attestation is requested?

                    This is done by your IT admin, or at least it should.

                    schweizer Is enterprise attestation enabled or disabled by default when I register a hardware key for a company M365 account?

                    Depends. Again, such attestation (registration) is done by your IT department. So you would (should) know when receiving the key from IT.

                        fid02 I found an article by Yubico which explains the difference between a basic attestation level and the enterprise attestation level:

                        Thank you, this answers my questions.

                        For those who don't want to read the whole article: You are possibly using Enterprise Attestation when you got a special Yubikey by your employer or you are using a special browser provided by your employer.

                            schweizer Note, there's nothing special about the yubi provided by your company in terms of hardware. Same key can be bought by you and will not have EA. It's how it is registered with the management service by your company.