Hacker News Reader

Comment by potatoz2 | Hacker News Reader

I don’t think it’s true for the hardware token. The initial registration sends information about the token to the website (but the website can tell the browser it doesn’t need it, IIRC).

View on HN

WebAuthn supports sending an attestation certificate during the initial registration. But with an implementation according to the spec this certificate only identifies the model of the security key used and thus is shared across a 5 to 6 digit number of physical keys.

This attestation is meant to allow the service to verify that you use a "blessed" security key with certain security properties (e.g. only a YubiKey 5 they verified to be secure and not some random $5 key with broken RNG off Amazon).

This is bad. This, for example, allows sites to accept only government-approved hardware keys with backdoors and do not accept self-made secure keys.

This is intentional, given that “self-made” keys have plenty of ways to be insecure, and the average user cannot tell the difference between a well made key and one that is either accidentally or intentionally defective in ways that affect their security.

FIDO2 is designed to maximize security for the majority of users, and the majority of users are using Yubikeys or other hardware-backed tokens provided by big players in their space.

This doesn't make sense. As a website author, why would I visibly restrict the security keys to backdoored government keys, when I can simply give the government an invisible backdoor API or direct database access?

Reply on news.ycombinator.com