Ensuring biometric protection

Fantastic and informative video! I'm looking to add passkeys as an authentication option for my site, but I want to make sure that when they are used they satisfy strong authentication. I know passkeys are supposed to be interoperable across operating systems, and I know the video mentions that Apple will always require passkeys to be protected by biometrics, but how can I ensure that passkeys from other operating systems are protected by biometrics? Is there a particular claim on the passkey that contains this information, or would we need to rely on the operating system of the client/authenticator (which can be spoofed)?

Accepted Reply

What kind of attacks are you trying to prevent against?

If you're concerned about:

  • Phishing: passkeys already solve this, and biometrics don't provide any additional protection against this attack.
  • Weak credentials: passkeys already solve this, and biometrics don't provide any additional protection against this attack.
  • Reused credentials: passkeys already solve this, and biometrics don't provide any additional protection against this attack.
  • Guessable credentials: passkeys already solve this, and biometrics don't provide any additional protection against this attack.
  • Credential stuffing attacks: passkeys already solve this, and biometrics don't provide any additional protection against this attack.
  • Data breaches: passkeys already solve this, and biometrics don't provide any additional protection against this attack.

If you have a significant threat model that includes attacks not mentioned above, you're already in a very small subset of RPs relative to most of the internet :).

Assuming solving for all of the above doesn't meet your needs, if you're concerned about:

  • Sync account compromise: Compromising a sync account alone is generally not enough to grant to access to passkeys. For details on how iCloud Keychain handles passkeys under various threats, see About the security of passkeys. Biometrics wouldn't provide any additional protections here.
  • Device theft: Under this threat model, your scope of attackers has decreased from the entire planet down to someone physically close enough to interact with the user. In the majority of cases, the device is locked when stolen, so the device's own lock mechanism should already be sufficient and biometrics on the passkey don't provide any additional protection.
  • Device theft where the attacker knows the user's device password/passcode: The attacker could unlock the device, and they could also use the password/passcode to enroll their own biometrics, so performing biometrics doesn't provide any additional protection.
  • Device theft of an unlocked device where the attacker doesn't know the device password/passcode: If an attacker is able to steal a device while it is unlocked, but doesn't know the device's password/passcode, this is the only listed scenario where biometrics do provide additional protection. This has further limited the attack surface down to attackers in physical proximity who have access to the unlocked device. Biometrics in this case provide as much protection as knowing the device's password/passcode (due to the reasoning in the above bullet), so password/passcode/biometrics are equally strong in this scenario. In this extremely small attack surface, you can check if at least one of password/passcode/biometrics were used, by checking the User Verification (or UV) bit in the response.

Every knob has a cost, so it's important to fully work through the actual value being provided vs the actual cost of turning that knob before reaching for it 🙂.

Replies

What kind of attacks are you trying to prevent against?

If you're concerned about:

  • Phishing: passkeys already solve this, and biometrics don't provide any additional protection against this attack.
  • Weak credentials: passkeys already solve this, and biometrics don't provide any additional protection against this attack.
  • Reused credentials: passkeys already solve this, and biometrics don't provide any additional protection against this attack.
  • Guessable credentials: passkeys already solve this, and biometrics don't provide any additional protection against this attack.
  • Credential stuffing attacks: passkeys already solve this, and biometrics don't provide any additional protection against this attack.
  • Data breaches: passkeys already solve this, and biometrics don't provide any additional protection against this attack.

If you have a significant threat model that includes attacks not mentioned above, you're already in a very small subset of RPs relative to most of the internet :).

Assuming solving for all of the above doesn't meet your needs, if you're concerned about:

  • Sync account compromise: Compromising a sync account alone is generally not enough to grant to access to passkeys. For details on how iCloud Keychain handles passkeys under various threats, see About the security of passkeys. Biometrics wouldn't provide any additional protections here.
  • Device theft: Under this threat model, your scope of attackers has decreased from the entire planet down to someone physically close enough to interact with the user. In the majority of cases, the device is locked when stolen, so the device's own lock mechanism should already be sufficient and biometrics on the passkey don't provide any additional protection.
  • Device theft where the attacker knows the user's device password/passcode: The attacker could unlock the device, and they could also use the password/passcode to enroll their own biometrics, so performing biometrics doesn't provide any additional protection.
  • Device theft of an unlocked device where the attacker doesn't know the device password/passcode: If an attacker is able to steal a device while it is unlocked, but doesn't know the device's password/passcode, this is the only listed scenario where biometrics do provide additional protection. This has further limited the attack surface down to attackers in physical proximity who have access to the unlocked device. Biometrics in this case provide as much protection as knowing the device's password/passcode (due to the reasoning in the above bullet), so password/passcode/biometrics are equally strong in this scenario. In this extremely small attack surface, you can check if at least one of password/passcode/biometrics were used, by checking the User Verification (or UV) bit in the response.

Every knob has a cost, so it's important to fully work through the actual value being provided vs the actual cost of turning that knob before reaching for it 🙂.