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.)
If you read the proposal carefully. this api is used to refresh/revalidate extremely short lived cookie. not replace cookie itself. Which you can already do with webauthn
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's impossible to start a new passkey provider because you'll never get 1000s of websites to put you on their allowlist.
You ignore history. and human nature.
Everyone will just hardcode a big `if microsoft || google || apple` and call it a day. And over time local gov will require companies under their TLD also add gov.TLD and that will be status quo forever.
As other commenters mentioned, EU official login (which accepts SMS but not TOTP!!!) already works with passkeys with only weird approved devices (mostly android/ios apps which try very hard to detect non-stock roms)
> On one side, there are sites with regulations that they are supposed to meet
I find it rather hard to believe there are websites subject to regulations that are impossible to comply with today?
Are you sure you didn't hear this from someone creatively interpreting some unrelated regulation? Standards committees are always full of people trying to cram their employer's patents and products into the standards.
Disclaimer Corbado Co-Founder here: That passkeys (WebAuthn) as a standard can support different levels of security requirements in the future on a common ground is probably the best thing. Even with an unknown new passkey provider, that's still more secure for the average consumer on a broad scale with legitimate passkey providers being 99.9% of the market. For regulated entities, that's an important area of extension. But even for banks, passkeys can easily replace the first factor, as phishing there is the biggest concern. I would argue that Passkeys+SMS OTP for banking is probably far more secure than any other option currently available (even with the sad security of SMS OTP), just because consumers cannot give their First-Factor voluntary away to phishing... Well maybe not better that any option but a lot of them.
I want to self-host my account credentials. Or more accurately, I absolutely do not want Apple | Google | Microsoft to be able to lock my account, and thereby lock me out of every other account. Especially as two of them have already done so.
If I could act as a passkey provider for myself, similar to how I can do that with SSH, then that’d be great. I do not comprehend why it’s not allowed, apart from being part of a further grasp for power by those companies.
Well, you can store your passkeys in a password manager like KeePassXC. Open-source password/passkey manager actually means more or less self-hosting your credentials as a third-party provider.
(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.
Aha, so it is part of the spec. Thanks for clarifying that. Appreciate the advice on discoverable credentials as well! I was probably leaving out the discoverable creds from the allowlist. Getting the timing down for when to ask for credentials was a bit tricky but I think I see the whole picture now.
I will say though, when it all works out it's a really nice way to log in, and my users are happy about it.
But in every FIDO2 registration there is a pop up for both Android phones and USB security keys with the API call. The prompt for registering a device shows both "Add a new Android phone" or "USB security key". When you click on "Add a new Android phone"it leads to a barcode that when you scan nothing happens. Seems real confusing especially if they want broader adoption.
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?
I guess a ~10kohm resistor in series couldn't hurt, should something go wrong. After all your finger is not exactly super conductive in the first place...
I'm not 100% sure either and am looking into it. FIPS is a rats nest and it may "depend." At this point I was just looking for basic feedback as to whether anyone could see any obvious problems. One person did suggest using a different AES key for each operation, which costs next to nothing and is probably good practice.
Edit: plan is to re-key often enough than plain GCM with 64-bit tags would be "fine" from a FIPS point of view. The goal here is to do better than the FIPS requirement by closing a potential attack vector.
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.
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...