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.
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.
What's the deal with lost yubikey user workflow? Rely on individual websites to give you a one-time recovery passcode that you then have to input into every website? I can't believe I'm taking UX cues from cryptocurrencies, but what about providing the user with a seed for the yubikey private key they can back-up offline then reinstall in a new yubikey?
P.S. just ordered a yubikey security key, excited to add this additional layer to my own personal byzantine security labyrinth. Or maybe simplify it, who knows!
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 can use Trezor or Ledger hardware wallets for U2F with recoverable seed words. Even if you go with a Yubikey, which has a better form factor, one of these is a pretty good backup device since they can be further backed up to paper.
> 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.
No, since passwordless login is available, the lowest denominator applies: single factor. Despite all your efforts it will most likely be possible to perform a passwordless login even when password is required in a few years (as these things get broken). The something you know is useless, as it can be ignored. And because it can, it will. Either by force, by negligence or by laziness.
Maybe I misspoke - by "optional" I meant "optionally required". The server can require the use of a PIN - and although the PIN verification is done client-side, the authenticator (YubiKey) sets a bit in the signed response to indicate whether PIN was used. The server can then verify the authenticity of the bit if it trusts the authenticator's attestation certificate.
It's also allowed for authenticators to always require PIN even if the server doesn't, but the current YubiKey obeys the server's preference.
But yes, there will of course be bugs. But that is also true for password logins, so I don't see it as a particularly convincing argument.
A PIN is really a numeric password. It has all the same flaws - compromise risk (say via social engineering) and the risk of forgetting and needing it reset.
So the ‘passwordless’ option here is either rename the password to PIN or eliminate it to provide single-factor login. The latter is a dream for smart attackers, since there is always some social engineering route they can use to acquire a legit token.
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.
Not all the same flaws; malware will have a much harder time recovering it. Also, you can use a regular password to "semi-authenticate" with the call center of the service and try to get them to disable the second factor, but this PIN is only useful with physical access to the device.
The key feature of security tokens is that it’s very difficult to extract or manipulate their internal state. A short numeric PIN enforced by a token is much more secure than a high-quality password whose hash is stored in a database: the token can rate limit PIN attempts and zeroize itself if too many attempts are made.
The FIDO U2F and WebAuthN standards explicitly address this issue, because it is a valid concern. No, your key cannot be detected as being the same key on website A and B.
Undoubtedly the same holds true for these Microsoft services.
What Freak_NL said. No, there is no globally correlatable identity, and it won't be possible to either create or authenticate credentials silently. Browsers will show confirmation popups and YubiKeys will start blinking to prompt for touch confirmation.
I wasted so much time and energy on implementing U2F for a web application, writing server side lib and making the javascript framework compatible with the horrible js-hack that's available for U2F support.
It was all in vein; the browser support is still horrible, no one want to use it and it's not possible to use on mobile. How can you make a security solution that doesn't work on mobile?
Making a new "Web Auth" standard is a huge mistake, and I will not fall into that trap again.
I ran into this with GitHub. I ordered a YubiKey, got it all set up with GitHub, and… never use it. Because it's not supported on mobile or in Safari.
If anything, the web needs technology that allows browsers to present secure third-party auth to web services (e.g. through TouchID, the way that Apple Pay works on Safari and Mobile Safari).
Do you have any information when any major websites will (may?) support U2F in Firefox? Google, FB etc. Is there some issue with Firefox U2F implementation maybe? Thanks.
From what I understand, Firefox doesn't implement the whole U2F spec, and Google and Facebook use some of the features (appID facets) FF left out. However, Firefox, Chrome and Edge all plan to implement the whole Web Authentication API.
Github works fine with U2F in Firefox, I think the problem is just that Google is doing browser detection rather than capability detection. (Of course they do, since they want to underhandedly promote their own browser).
Do you have any plans to release server code (I'm mainly concerned about PHP) for CTAP2/WebAuthn support? I really appreciated having access to a reference implementation to handle the data from the client for U2F. CTAP2 looks significantly more complex, and I'm somewhat worried about complexity of implementing it correctly based on the spec.
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.
I'm thinking of writing a Django-webauthn library (although I'm not sure if it would just be simpler to fork django-u2f). Would the Python library help at all? It looks like it's for USB communication and not for general helpers around signing/authentication/etc.
It's mostly for host-authenticator communications, yes, but it it includes a couple of helpers for verifying signatures. But you're right it's not a full-featured server library at this point.
> 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"
If "something you know" is physically stored on "something you have", doesn't this make "something you know" completely moot?. Please explain how this doesn't simply reduce to "something you have". In other words, if someone steals your Yubikey, can they login as you without knowing anything additional?
They will not support FIDO2, but they do support U2F which is compatible with a subset of the FIDO2 features. Specifically, they don't support PIN or username-less login, but they CAN be used as 2nd factors (emphasis on the 2) in addition to conventional username+password login.
In a sense, yes, but the keyword is "on-device". It's not shared with the server, so it can't be remotely intercepted - but it _can_ be changed in a single place (the YubiKey) should it ever be compromised.
Oh, maybe I didn't get the entire question. There's no global identity or "root credential" used for all websites. A separate keypair is created for each website, and a keypair for site A is not usable on site B even if site B somehow has the public key.
It's not, you're misunderstanding and spreading misinformation. The "key to the kingdom" is a random asymmetric keypair. The PIN is only there as a second factor to this key to prevent physically stolen keys being used to authenticate. If you enter the PIN wrong five times, the device can just lock itself.
There might be a way to steal the PIN if the user enters it on a compromised machine, but you can't do anything with the PIN. You need the physical device as well.
I think you misunderstand how the CTAP portion of Webauthn works - once the root credential authenticates the user, they no longer have to use passwords for the user’s various accounts. The simple point is that if this credential became compromised for whatever reason, then all associated accounts are by definition compromised.
Wait a second. Web Authentication is not an SSO framework - there's no "root credential". Each server you use the token on gets its own keypair which is used for only that site.
It seems like the scenario you're describing in further replies is this: 1) Alice has an account at service A and an account at service B, and authenticates to both with the same FIDO2 token. 2) Eve calls service A and convinces them she's Alice and needs a new token. 3) Service A sends Eve a new token registered to Alice's account. 4) Eve uses the new token to log in as Alice at service B.
The above attack is not possible, since the keypair for service A is not usable at service B. This separation of credentials for separate services is a fundamental FIDO/WebAuthn design feature for damage control and user privacy. Eve can use the new token to log in to service A, yes, but only to service A.
Even if service A and service B were to try to cooperate out-of-band to support each other's credentials, the browser would not let them unless they're on the same domain.
Yes, certainly. And in order to compromise that root credential, you'd have to physically steal the key, and either decap the chip and read the bits somehow, or find a vulnerability that allowed you to read the private keys through USB.
Needless to say, this is much, much harder than stealing someone's password.
Credential reissue (lost token) would be a much easier path for an attacker. The weakest point is always the point of compromise. For the smart attacker therefore, they have been handed the whole set of accounts. So yes the original point stands - attackers will find it more lucrative to do account compromise in the Webauthn world.
They might call in and say they lost their token, and a competent attacker will usually have all the necessary info. Happens all the time with credit card fraud. Sure, you can notify the target that a credential was reissued, but that happens with credit cards too, and most of the time people don’t pay attention.
About 15% of the user population really cares about security and will take the right precautions. It’s the other 85% that are soft targets that keep attackers in business.
Okay, but how is that the key's fault? This has literally nothing to do with the authentication method, it doesn't give you access to any other site or anything. It's just a social engineering attack on the service, and it's pretty much the only one left because everything else has been obsoleted by the use of hardware tokens for auth.
I don't see how that's different from passwords, though. If your password gets compromised, it's game over as well, and it's much easier to compromise that.
I don't see that as a flaw really. It's not different to having a password manager, with proper WebAuthn atleast.
What you do is you take this key that unlocks the kingdom.
And then you keep it safe.
Unlike before there isn't 20 keys that unlock parts of the kingdom that might lead to unlocking other kingdoms via roundabout ways. Your attention for security can be focused on a single key.
The average users will be much safer if we force them to only have to remember one single password that can be securely used for everything without the usual drawbacks (that's why security people recommend password managers)
The flaw stems from the fact that an attacker can thru social engineeung acquire that root crendential (password or biometric or token). Once they have it, they can clean out all your banking, stock and home equity line accounts in one sweep. You as a user may not know that credential is compromised - maybe it was a key logger, maybe it was social engineering the cell phone provider to port your number and then qualify their phone with an sms token. You don’t know when that happened - you just see empty accounts.
With personal password managers, no third party is issuing tokens for access - just you. So it’s unlikley to be chosen for an attack - because it’s too hard for the attacker to acquire the credentials for access without detection.
No third party issues tokens in WebAuthn either - you have your one or a couple of authenticators you use everywhere, and those authenticators create their credential keypairs locally on the device (and a separate keypair is created for each site - they're not shared between sites).
Social Engineering is difficult problem with a solution quite simple; make the hardware resistant to replay attacks and don't give the user anything they can leak.
Password managers don't protect against this. People have given attackers their entire password vault, all you need is a convincing story about some security audit and you needing to review all their passwords. Users believe this.
The solution there is to take away the things a user can leak (passwords) and replace them with things that can only be stolen (tokens). We can train users to never give away their yubikey. Of course some will still fall for social engineering but for a yubikey/equivalent it's fully acceptable to say "never ever never give to anyone, no matter what they say".
Whether you use a hardware key, or a password manager, in both cases the attacker needs both authentication factors: your password, and the hardware key or password manager.
With a hardware key you gain the advantage of the attackers having to physically gain access to that key.
This is the misunderstanding attackers can exploit. Credentials need to be reissued because people lose them ocassionally. So that process now becomes a pathway for exploits.
No - that process _remains_ a pathway for exploits against the particular website being targeted. The process does not open new pathways for transferring exploits from one site to another - on the contrary, such exploits are made more difficult by the separation of credentials.
To be more precise, the PIN is the key that unlocks the keyring (the hardware token) that contains the keys (asymmetic keypairs) to the various kingdoms (websites). WebAuthn is not a single sign-on framework, and there's no "root credential" that's used everywhere.
- 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.