Comment by crote
8 days ago
The vibecoding part is probably because "userVerification: required" is essential to have it work somewhat-securely as your sole form of security - like Passkeys is heavily promoting. Without it anyone with physical access to the device can use it to log in. This might not be so bad for a password manager which already has strict session password requirements and short timeout periods of its own, but it is a completely different story with, say, a Yubikey.
If you're building a Passkey-based login page and you specify "userVerification: preferred" or "userVerification: discouraged" you are essentially reducing your security to a single factor - namely the "something you have" one.
> Without it anyone with physical access to the device can use it to log in
No, they would need to be able to log onto the device and have the password manager unlocked.
If your passkey is stored in a Yubikey and someone steals it, then how does this feature help you? When the thief plugs the stolen Yubikey into their own Windows account, what is Windows going to do? Ask the thief for the thief's own password? How does that help?
The vibe coding attempts I tried weren’t passwordless. For the actual passwordless internal system, AAGUID is checked so only whitelisted password managers are allowed, “something you have” hardware keys are not accepted. I know AAGUID can be spoofed but employee somehow hacking part of the process just to register a hardware key against policy isn’t really part of the threat model.