emlun

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 best recommendation right now is to have a backup key, but it still means you have to register it everywhere in advance and then go to each site to revoke the lost key.

At least Web Authentication platform credentials should let you have multiple authenticators without having to buy an extra YubiKey.

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's true for _any_ "something you know" factor including conventional passwords. The whole point of multiple factors is that they have _different_ sets of weaknesses.

Also: unlike a shared secret like a password you share _everywhere_ (and let's face it, most people do), an on-device PIN can be changed in a single place should it ever be compromised.

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://github.com/Yubico/python-fido2/

https://github.com/Yubico/java-webauthn-server

>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 "platform authenticators" - some kind of TPM/secure enclave etc. built into the computer (most likely a laptop/phone), possibly integrated with a fingerprint scanner. The expectation is that sites will let you register more than one credential (like many (most?) do for U2F), so you can have a keyring device for initial logins on new computers (or for logging in on a friend's computer) and then use a platform credential on each for most daily use. Intel's built-in U2F thing is something to this effect, and might be compatible.

It's also theoretically possible that a phone could expose its platform authenticator to other computers via Bluetooth/NFC/USB, but that's still hypothetical at this point.

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 isn't shared with the server, like conventional smart cards. This allows the key to act as both "something you have" (the key itself) and "something you know" (the PIN for the key). The PIN is optional, though, so both the single factor and two factor use cases are possible.

- Q: Is this Azure/Windows/AD only?

A: This post highlights the partnership with Microsoft and the integration with their products, but FIDO2 is not Microsoft-only (and Yubico will not be the only key vendor). CTAP2, once finished, will be published as an open standard like U2F, and the accompanying Web Authentication API [1] (WIP) is an OS-agnostic W3C standard enabling the same features in browsers.

[1]: https://www.w3.org/TR/webauthn/

- Q: Will I need a new YubiKey?

A: For passwordless (PIN) login, yes. However, existing YubiKeys with U2F support will be usable as a 2nd factor in Web Authentication, and sites that currently use U2F can upgrade to using the Web Authentication API without needing their users to re-enroll their keys.

Full disclosure: I'm a Yubico engineer and one of the editors of the Web Authentication spec.

>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 attempts per second. :)

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.

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 supports storing the private key along with some metadata on the device, whereas U2F instead encrypts the private key and stores the ciphertext on the server. While the encryption approach allows for simpler hardware and an unlimited number of registrations, the local storage approach allows login without even having to type (or even have) a username. CTAP2 supports both.

- CTAP2 has an extensions framework in which an authentication vendor and server can cooperate to implement custom features without the browser having to understand them.

- CTAP2 - or at least the companion web API, Web Authentication - is compatible with more existing TPMs and such hardware. For example, it's theoretically possible that some Android phones could receive software upgrades that turn their fingerprint sensors into WebAuthn authenticators.

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.

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 2nd factors in the browser, but they don't support the passwordless use case.

The two factors are a) the YubiKey and b) the PIN for the YubiKey.

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.

That's exactly how FIDO2 PIN on the new YubiKeys works.

>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 choose an authenticator vendor that's widely trusted to make high quality hardware. If you don't trust Yubico, there are competitors.

>the protocol is so complex that chances are high that even implementations can contain bugs

This is only partly true - most of the complexity is in the browser and authenticator layers, and are implemented by cryptography experts in the browser teams and authenticator manufacturers. Almost all of the server layer complexity can be encapsulated in reusable open source libraries - app developers will only have to implement their business logic on top of it, just like they have to do for password authentication too.

>do you really think that having a complex system will be better?

It will eliminate the problems with phishing and password reuse. That is definitely better in my book.

>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 such a failure case is not possible, for two reasons. First, no secrets are shared - the server only sees _public_ keys and signatures. Second, a different public key is generated for each website - there is no globally correlatable identity.

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.

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 today [July] embedded in my gravel driveway where it must have been since January and been stepped on/run over since then. Popped it into the computer mostly for fun, and it works like a charm. :P Hardy stuff! :)

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. All that's sent to the server is a public key and a private key signature.

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 capabilities. And on the flip side, the user can opt in to biometric authentication even if the server does not require or care about it.

It also thwarts phishing and MitM attacks (assuming the browser is not evil), which OTPs do not.

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 fingerprint before unlocking the private key.

Apple does seem to be working on it: https://bugs.webkit.org/show_bug.cgi?id=181943

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.

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 private key. The authenticator also provides the server with its attestation certificate when you register it, and using that attestation certificate the server can verify what kind of authenticator it is and trust that the authenticator can be used as multiple kinds of authentication factor.

It is true that I don't know of any currently existing authenticators that support biometric authentication, but what's nice about this spec is that the biometric/PIN/etc stuff is never exposed to the server. When new kinds of authenticators enter the market (like if Google adds the feature in an Android system update), they can immediately be used without having to change any code on the servers. And like you say, even without the multi-factor stuff it'll be a fantastic improvement over the current dumpster fire that is passwords.

Full disclosure: I work at Yubico and am one of the editors of the Web Authentication spec.