> he new YubiKeys support an on-device PIN that isn't shared with the server
Doesn't this PIN become a master password for all the websites at that point?
Doesn't this PIN become a master password for all the websites at that point?
What you do is you take this key that unlocks the kingdom.
And then you keep it safe.
Unlike before there isn't 20 keys that unlock parts of the kingdom that might lead to unlocking other kingdoms via roundabout ways. Your attention for security can be focused on a single key.
The average users will be much safer if we force them to only have to remember one single password that can be securely used for everything without the usual drawbacks (that's why security people recommend password managers)
With personal password managers, no third party is issuing tokens for access - just you. So it’s unlikley to be chosen for an attack - because it’s too hard for the attacker to acquire the credentials for access without detection.
With a hardware key you gain the advantage of the attackers having to physically gain access to that key.
Password managers don't protect against this. People have given attackers their entire password vault, all you need is a convincing story about some security audit and you needing to review all their passwords. Users believe this.
The solution there is to take away the things a user can leak (passwords) and replace them with things that can only be stolen (tokens). We can train users to never give away their yubikey. Of course some will still fall for social engineering but for a yubikey/equivalent it's fully acceptable to say "never ever never give to anyone, no matter what they say".
No third party issues tokens in WebAuthn either - you have your one or a couple of authenticators you use everywhere, and those authenticators create their credential keypairs locally on the device (and a separate keypair is created for each site - they're not shared between sites).
There might be a way to steal the PIN if the user enters it on a compromised machine, but you can't do anything with the PIN. You need the physical device as well.
Needless to say, this is much, much harder than stealing someone's password.
About 15% of the user population really cares about security and will take the right precautions. It’s the other 85% that are soft targets that keep attackers in business.
It seems like the scenario you're describing in further replies is this: 1) Alice has an account at service A and an account at service B, and authenticates to both with the same FIDO2 token. 2) Eve calls service A and convinces them she's Alice and needs a new token. 3) Service A sends Eve a new token registered to Alice's account. 4) Eve uses the new token to log in as Alice at service B.
The above attack is not possible, since the keypair for service A is not usable at service B. This separation of credentials for separate services is a fundamental FIDO/WebAuthn design feature for damage control and user privacy. Eve can use the new token to log in to service A, yes, but only to service A.
Even if service A and service B were to try to cooperate out-of-band to support each other's credentials, the browser would not let them unless they're on the same domain.