agl
Joined 19 years ago
Karma
2,229
Submissions
249
Member since
Aug 15
Recent submissions
Comment · 1 year ago
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].
[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...
Comment · 1 year ago
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.)
Comment · 2 years ago
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.
Comment · 2 years ago
> The popular libraries seem to follow a kind of "shadow spec" where they agreed on using the URL-friendly variant of base64
WebAuthn itself uses base64url rather than base64. See, e.g., the `id` field here: https://www.w3.org/TR/webauthn-2/#iface-pkcredential
(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.
Comment · 2 years ago
Comment · 4 years ago
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?
Comment · 4 years ago
Support is not yet available on Android but support for syncable passkeys on Android was announced for some time this year at Google I/O.
Comment · 6 years ago
You can just glue a wire to the touch plate and connect it to ground when you want to simulate a touch.
Comment · 7 years ago
I do not represent an NVLAP lab, but I'd question whether this would pass strict muster for FIPS given IG A.5: https://csrc.nist.gov/csrc/media/projects/cryptographic-modu...
(Disclaimer: author of AES-GCM-SIV. Not casting shade here, it's a fair idea! But not sure about the specific FIPS claim.)
Comment · 7 years ago
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.
Comment · 7 years ago
Comment · 7 years ago
Early support should be appearing in the coming weeks on Canary channel when run with --enable-features=WebAuthenticationPINSupport
Comment · 7 years ago
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?
Comment · 8 years ago
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.
Comment · 8 years ago
> 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.)
[1] https://www.w3.org/TR/webauthn/#attestation-convey [2] https://www.w3.org/TR/webauthn/#fido-u2f-attestation [3] https://fidoalliance.org/mds/ [4] https://www.imperialviolet.org/2018/03/27/webauthn.html#atte... [5] https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-cl...
[ my public key: https://keybase.io/agl; my proof: https://keybase.io/agl/sigs/tG9pHxVSSV14w9KD5hAohdi2NkDNPxULyFKL-OATzP4 ]