Renaud Lifchitz 
Forging Passkeys: Exploring the FIDO2 / WebAuthn Attack Surface
https://www.nullpt.rs/forging-passkeys
https://www.nullpt.rs/forging-passkeys
Firstyear@nono2357 also its the nonce in each assertion that prevents replays, not anything else. So unless you are suggesting there is a nonce replay here that works, there isnt actually a replay attack, just a new software authenticator that you made.
The issue is software authenticators like a pw manager are doing exactly what you did to work, they cant be attested and nor can they have a consistent signcount. Again fresh nonces are what prevent replays.
So most big players have said for general public, "whatever authenticator is better than a password". For serious orgs, they do attestation and hardware keys only.
The issue is software authenticators like a pw manager are doing exactly what you did to work, they cant be attested and nor can they have a consistent signcount. Again fresh nonces are what prevent replays.
So most big players have said for general public, "whatever authenticator is better than a password". For serious orgs, they do attestation and hardware keys only.
Varbin 
@firstyear @nono2357 Yep. I fail to see the real vulnerability for the common use cases, too.
Additionally, how the user is verified the user at registration (so the user is allowed to register a passkey) is explicitly out of scope of the standard(s). The "attack" of the article could be a regular phishing attack, to, where the attacker just steals the session token to register a new passkey.
Even if a public facing site would perform an attestation, it would not help at all. Attention just attests some security properties, but not does not attest trustworthiness.
Also as long as the enterprise attestation (which is usually limited by the devices) is not used (providing the real serial number, and not just the batch/model AAGUID), an attacker could just relay the registration calls to its local off the shelf Yubikey.
@varbin @nono2357 Attestation is a proof of where the private key is held, and how user verification is performed. So for something like a yubikey if it attests that its key is in an SE and UV actually does check the pin and touch is enforced. Its just about establishing those properties on first use. Without that, UV is just a "yolo i guess i checked something" signal.
Ultimately its down to threat model and which risks you will allow for your users credentials.
Ultimately its down to threat model and which risks you will allow for your users credentials.
@firstyear @nono2357 In my example I would relay all CTAP commands to a remote Yubikey, including the registration commands. The attestation will then attest the key resides in a Yubikey, but not the key the user owns.
@firstyear @nono2357 In my imagined attack the key would never leave the attacker-controlled remote Yubikey. The user will discover the attack when they try to use their Yubikey on another, non-comprised device.
My point is that on a fully a compromised device, you cannot register securely, and even attestation will not protect me fully.
@firstyear @nono2357 I agree, though I am not sure what could help against full client/browser compromise. At least with a hardware base authenticator (or an off device software based on connected over the hybrid scheme) does not let an attacked extract the authentication secret.
The standard(s) and security guide suggest authenticators should have a display against some attacks, but I believe there are only a handful of authenticators (if any) with it (besides previously mentioned phones as a hybrid one). Security at registration time is only covered by enterprise registration.