Setting a signature counter to constant zero is explicitly supported[1] and it's not a bug that it works. Google does not require the signature counter to increment; it's something else invalid about the response that's tripping it up.
The security story for signature counters is subtle[2] and the vast (vast) majority of sites are correct not to require them.
Using the Chrome virtual authenticator indeed works, and from the DevTools UI directly (three dots -> More Tools -> WebAuthn), no sockets required. It's not a vulnerability that it works. If it didn't, Apple, Google, and Microsoft would be effectively the only possible passkey providers. You can lock it down in enterprise environments if you need[3].
WebAuthn protects the sign in, but malware can still steal the resulting cookies. DBSC protects the sign in _session_. (It should stand for Don’t Bother Stealing Cookies.)
It is a fair worry. On one side, there are sites with regulations that they are supposed to meet and it's hard to do so without knowing something about the passkey provider. If we want to try and replace SMS OTP, which is depressingly easy to compromise, we can't ignore such things.
On the other, we don't want to create a situation where it's impossible to start a new passkey provider because you'll never get 1000s of websites to put you on their allowlist.
So far, we haven't done attestation for passkey providers at all. There is only the AAGUID, which is a spoofable identifer should any sites try to filter based on it. There are legitimate cases where sites are required to know more, but we're trying to find a path that doesn't lead to the problems that you worry about and, so far, are erring on the side of openness.
(It was probably a mistake, but it predates me so I don't know the motivation.)
> I still don't know whether it's possible to use both usernameless and usernameful passkeys simultaneously.
Non-discoverable credentials can only be used if their credential ID is passed in an allowlist. Discoverable credentials (a.k.a. "resident" in the API, although that name is a bit misleading) _can_ be enumerated in an allowlist. So they can work together, but to have the allowlist you must collect a username first or have some other way of know which account is pertinent to the current session.
2nd-factor WebAuthn should work fine with Android phones today. Any Android phone with a current version of Play Services and Chrome should be able to scan the QR code, if it doesn't work then it's a bug (or, at least, an old QR scanner).
When you say "nothing happens": what's the QR scanner? Do you have Chrome installed on the device? What are the app versions (from Settings) of Play Services and Chrome?
getrandom blocks until 128 bits of entropy have been collected since boot. It doesn't have the concept of "draining" the pool after the pool has been initialised.
There are various groupish signature systems (including DAA and BBS[1]) that would probably be a better answer here, _if you controlled the signers_. But, in this context, the devices have shipped and they do P-256 ECDSA. So the question then becomes, what _can_ we do without being able to change the signers? Can we plausibly retrofit something onto them?
Google has not yet transitioned from the U2F API to the Web Authentication API for login so no, not yet. (We're working on it, but there's quite a lot of moving pieces.)
Also, as another comment noted, only CTAP2 is supported for the host to authenticator API, and only the newest Yubico tokens support CTAP2.
> Is there anything in the standard about proving to the server that you have a genuine FIDO device
Yes. When registering a credential you can request[1] attestation information. Generally this will come in the form of an X.509 certificate[2] per batch of 100,000 devices which is signed by the manufacturer and which signs the generated key.
FIDO is planning on running a central registry[3] of devices which should include their certifications and manufacturer public keys etc.
For more details, see [4].
> My understanding of FIDO (v1) is that the only function a device has to offer is authentication through digital signature.
That's correct: CTAP1 just signs things. You can prove to a remote service that the credential is in live use right now because it signs over a server-provided nonce to show freshness, but that's all.
With CTAP2, devices can store keys themselves and they can provide a random oracle (i.e. HMAC) for unlocking locally encrypted data[5]. FIDO2 devices can also require a PIN to be provided before keys are released. (Or have a local fingerprint reader, although I don't know of any such devices yet.)
Webauthn and WebUSB UIs are very different. Additionally, Chrome has banned WebUSB from claiming Security Keys.
However, it remains the case that if the user downloads and runs exes, or otherwise grants the attacker direct access to the Security Key, then they can ask it to sign an authentication request for a given website. Such an attacker could also compromise the browser and wait for the user to login themselves etc.
Webauthn works with both FIDO1 and FIDO2 keys. (Unless you have the new, FIDO2 key from Yubico then you have a FIDO1 key). You might also see them called CTAP1 and CTAP2 keys because CTAP is the bit of FIDO that defines the interface to the hardware tokens. (CTAP: "Client to Authenticator Protocol". See https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-cl...)
FIDO2 keys talk a different protocol and do everything that FIDO1 keys do, and (potentially) more. For example, they may operate in "resident key" mode where the key remembers both your username and private key. They can also support things like PIN activation.
I've only briefly poked the Yubico FIDO2 key. I think it supports a limited form of resident keys and it advertises PIN support, although I didn't exercise that.
Sorry, I worded that poorly. U2F keys will continue to work fine, it's just the Javascript API that sites use that'll change. As a user, everything will keep working.
Webauthn allows (but does not require) a mode where the key is a single-factor (i.e. acts as both username and authenticator). You need FIDO2 keys for that and we plan to support it in Chrome. Sites will decide whether that makes sense for them.
> However, I've heard that Google is kind of going on a tangent with its own U2F implementations, emphasizing an old-school implementation instead of the Web Authentication Standard that's pushed by the W3C.
Chrome has supported "U2F" (the first FIDO spec) for a while and all support for Security Keys in the last few years has been via this protocol.
But we're implementing the W3C Web Authentication (webauthn) spec and you can already use it in Chrome in place of U2F. All effort is going into webauthn now and the U2F code is frozen. At some point I'll announce a sunset date for U2F support in Chrome and happily delete that code. (Just the API, U2F keys will continue to work via webauthn.)
The security story for signature counters is subtle[2] and the vast (vast) majority of sites are correct not to require them.
Using the Chrome virtual authenticator indeed works, and from the DevTools UI directly (three dots -> More Tools -> WebAuthn), no sockets required. It's not a vulnerability that it works. If it didn't, Apple, Google, and Microsoft would be effectively the only possible passkey providers. You can lock it down in enterprise environments if you need[3].
[1] https://www.w3.org/TR/webauthn-3/#sctn-sign-counter [2] https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn... [3] https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn...