emlun

9 ms·

31.
by emlun 8y ago
It's still a largely unsolved problem, unfortunately. Enabling private key backup comes with a suite of nasty problems like what it means for device attestation and how to guarantee that a key hasn't been cloned in transit. Our be
32.
by emlun 8y ago
You would have been right if not for the important keyword "on-device". The PIN does not risk being exposed by server breaches, because it's never on the server. Yes, it can be extracted via clever con artistry, but that&#x27
33.
by emlun 8y ago
We have C, Python and Java libraries released right now, all of which are beta WIP as we don't yet have any users who can inform the API designs from real world use cases. https://github.com/Yubico/libfido2 https
34.
by emlun 8y ago
>I also really hope that hardware tokens like a yubikey are not required for every site or app. I'd like to be able to keep private keys on my phone or laptop for some things Web Authentication supports this with what's called
35.
by emlun 8y ago
I'd like to try to answer some common questions I see here: - Q: Doesn't passwordless mean single factor? Isn't that insecure? A: It could mean single- or two-factor. FIDO2 and the new YubiKeys support an on-device PIN that i
36.
by emlun 8y ago
>brute force the cryptographic key, which should be infeasible. Not only infeasible - physically impossible, in fact (barring quantum computers). Just 128 bits of entropy would take 1e16 (10 quadrillion) years to brute force at 1e15 atte
37.
by emlun 8y ago
As xur17 points out, these devices support an on-device PIN like smart cards. The protocol also has support for future devices with biometric authentication, which could give you all three factors in one device.
38.
by emlun 8y ago
Some differences: - CTAP2 supports "user verification", such as PIN or biometric authentication locally on the hardware key. This enables using the key as both 1st and 2nd factor without need for a server-side password. - CTAP2 su
39.
by emlun 8y ago
Depends on what features you want. The old U2F YubiKeys are compatible as 2nd factor keys, but they don't support the passwordless (PIN) or username-less (user ID stored on device) use cases.
40.
by emlun 8y ago
The U2F keys are compatible with at least the Web Authentication API ("U2F 2.0" / "FIDO2 in the browser"), but I'm not sure about the Windows/AD integrations. But in any case, the U2F devices will work as
41.
by emlun 8y ago
The two factors are a) the YubiKey and b) the PIN for the YubiKey.
42.
by emlun 8y ago
FIDO2 passwordless login can use a device-local PIN as a second factor, like a conventional smart card. The hardware key then acts as both first and second factor.
43.
by emlun 8y ago
That's exactly how FIDO2 PIN on the new YubiKeys works.
44.
by emlun 8y ago
>your public key is useless if twitter accidently logs challenges No, this is also incorrect. That's not how public key cryptography works. >your hardware is useless if key generation is too weak This is true, which is why you ch
45.
by emlun 8y ago
>Too bad if something like twitter happens your yubikey is probably useless after it would've prolly logged anything to their servers. Like krupan also points out, this is flat out incorrect. The FIDO2 protocols are designed so that
46.
by emlun 8y ago
The NEO and 4 series support U2F which can be used for FIDO2 2FA (emphasis on 2), but they do not support the passwordless (device PIN) or username-less login scenarios.
47.
by emlun 8y ago
Let me share with you an anecdote from a friend of mine: Lost my YubiKey around the start of the year and couldn't understand how it could have disappeared so I deregistered it everywhere and went back to Google Authenticator. Found it
48.
by emlun 9y ago
No, in webauthn they don't, because the biometric data is never sent to the server. The test is done locally, and the server can trust it (if it cares) by verifying a cryptographic attestation of the authenticator's capabilities.
49.
by emlun 9y ago
That's the nice thing about webauthn biometrics, though: the biometric data is never sent to the server. The test is done locally, and the server can trust it by verifying a cryptographic attestation of the authenticator's capabil
50.
by emlun 9y ago
It also thwarts phishing and MitM attacks (assuming the browser is not evil), which OTPs do not.
51.
by emlun 9y ago
It depends on what the server chooses to support, but the spec is designed so that it will be possible to support login without a password. Instead the authenticator (e.g., phone or USB dongle) would locally ask for a PIN and/or finger
52.
by emlun 9y ago
Apple does seem to be working on it: https://bugs.webkit.org/show_bug.cgi?id=181943
53.
by emlun 9y ago
Just to be clear: The tokens _can_ contain unique serial numbers in some vendor-specific format - but they MUST NOT be in the attestation certificate, so the WebAuthn API will never expose them to the server.
54.
by emlun 9y ago
I don't see what you mean is misinformative. The protocol is designed in such a way that an authenticator (e.g., a smartphone or a USB dongle) can check a biometric factor (or a PIN or something else) locally before allowing use of the