agl

7 ms·

1.
by agl 1y 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 tripp
2.
by agl 1y 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.)
3.
by agl 2y 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
4.
by agl 2y 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://
5.
by agl 3y ago
https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-t...
6.
by agl 4y 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 s
7.
by agl 4y 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.
8.
by agl 6y ago
You can just glue a wire to the touch plate and connect it to ground when you want to simulate a touch.
9.
by agl 7y 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-G
10.
by agl 7y 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.
11.
by agl 7y ago
https://json5.org
12.
by agl 8y ago
Early support should be appearing in the coming weeks on Canary channel when run with --enable-features=WebAuthenticationPINSupport
13.
by agl 8y 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 th
14.
by agl 8y 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
15.
by agl 8y 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 certifica
16.
by agl 8y ago
I don't know about the specific extension, but see https://groups.google.com/a/chromium.org/d/msg/blink-dev/LZX...
17.
by agl 8y ago
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 Sec
18.
by agl 8y ago
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
19.
by agl 8y ago
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
20.
by agl 8y ago
> 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 supporte
21.
by agl 8y ago
It's possible that new primitives based on the same SI problem might have significant performance differences, but we're basing this on the NIST round one submissions. In that setting, there's been a decent amount of optimisa
22.
by agl 8y ago
> Does that assume that all of the components (browser and server) support 1.2 as well? No: a client, server, and MITM proxy can all be exclusively TLS 1.3 and everything will still work(+). (+) as much as it did with TLS 1.2, anyway.
23.
by agl 8y ago
It does not. There are some passive decryption tools that will no longer work because they functioned by having non-forward-secure connections and the server's private key installed in the decrypter. (But one can just not support TLS 1
24.
by agl 9y ago
This is nonsense. The self-signature on a root certificate is irrelevant unless you can easily calculate second pre-images, and that's not true even of MD5, and accepting a root doesn't mean that the validator would accept that ha
25.
by agl 9y ago
XMSS is great work, but it's not clearly suitable for use in SSH: I will occasionally copy SSH private keys around, or restore them from backups. I think that's fairly common. However, with XMSS: "the signature schemes descri
26.
by agl 9y ago
The piece seems to suggest that a) multiple processes were the performance problem and b) that a field trial was causing that and "mak[ing] my computer unusable". Multiple processes do take more memory, but there's a good rea
27.
by agl 9y ago
The fact that Chromium runs multiple processes is unrelated to any field trials. Chromium has always been multi-process; that's why individual tabs and plugins can crash without taking down the whole browser. Additionally, multiple pro
28.
by agl 9y ago
Losing one.
29.
by agl 9y ago
"Basically, the code recurses a sha256 computation 1714 times to get a lookup key, and then once more to get a password for decryption." Other way around, no? The index is the hash of the decryption key (as it should be), it'
30.
by agl 9y ago
We are still working around bugs in network middleware. I hope that it will be available in Chrome and on Google's servers in Q1, 2018.

More ›