3

I'm starting to learn about the FIDO2 standard, and I'm wondering if this scenario is possible...

  1. Victim visits a credential harvesting page and enters their credentials
  2. Credential harvesting backend opens a connection to the legitimate login page and submits the stolen credentials
  3. Legitimate website presents a FIDO2 challenge
  4. The credential harvesting website presents the same challenge to the victim's web browser
  5. The victim signs the challenge and sends the challenge response to the credential harvesting site
  6. The attacker sends the challenge response to the legitimate website and authenticates as the victim

This answer on the Information Security Stack Exchange claims it is not possible, but I don't fully understand why. If a key pair is generated for for use only for a specific domain (enforced by the browser), the private key must be stored on a hardware key (such as a Yubikey)? Is that correct? What is the limit to the number of keys that can be stored, and what happens when that limit is reached?

kenlukas
  • 835
  • 6
  • 18
Sean W.
  • 835
  • 4
  • 14
  • 1
    No. The credential harvesting page would have a different FQDN than the legitimate site. Therefore, the keypair used to by the FIDO device to authenticate with the credential harvesting site would be different than the keypair used to authenticate with the legitimate site. See https://security.stackexchange.com/questions/257469/is-a-usb-security-key-trackable-among-websites for a similar question. – mti2935 Jun 18 '22 at 19:00

1 Answers1

2

I found the detail I was missing in this answer.

The TL;DR explanation (as I understand it anyway) is U2F devices can generate and store keys one of two ways

  • Generate and store separate keys and key metadata (including the FQDN according to the browser) for each website which would limit the number of keys to the amount of storage on the key
  • Use a wrapped private key, where the U2F device uses a master private key unique to the device combined with metadata to generate the separate private key dynamically but consistently for each site, allowing for an unlimited number of keys.

Yubikey takes the second approach.

Sean W.
  • 835
  • 4
  • 14