Yubico and Microsoft Introduce Passwordless Login(yubico.com)
yubico.com
Yubico and Microsoft Introduce Passwordless Login
https://www.yubico.com/2018/04/yubico-and-microsoft-introduce-passwordless-login/
217 comments
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!
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.
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.
I bought two Yubikeys and have one in a safe (mainly so I don’t lose it). This isn’t perfect though, as not all places support multiple keys :(
Recovery codes or 2 Yubikeys.
> 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.
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.
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.
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.
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.
Does it identity you as the same person to two different websites? I.e. Is it for building up advertising profiles like google oor facebook logins?
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.
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.
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).
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.
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).
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.
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.
https://github.com/Yubico/libfido2
https://github.com/Yubico/python-fido2/
https://github.com/Yubico/java-webauthn-server
https://github.com/Yubico/libfido2
https://github.com/Yubico/python-fido2/
https://github.com/Yubico/java-webauthn-server
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?
> 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?
Is there word on whether Yubikey 4 models will support FIDO 2? Or do we have to wait for a new model?
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.
> he new YubiKeys support an on-device PIN that isn't shared with the server
Doesn't this PIN become a master password for all the websites at that point?
Doesn't this PIN become a master password for all the websites at that point?
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.
That’s really the flaw of single sign-on and Webauthn - that one key now unlocks the kingdom.
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.
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.
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.
See CTAP in FIDO2 - something needs to determine you are the user before opening up the key set. The attack point will be at this step.
I'm sorry, I don't understand at all what you mean by that.
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.
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.
I think you misunderstand how WebAuthn works - see my other reply to your previous message.
How would an attack without having the hardware key work?
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.
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.
Not finding fault. The point of Webauthn is convenience - but the trade off is that if CTAP is compromised, it’s convenient for the attacker too.
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.
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.
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)
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.
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.
I think you misunderstand how WebAuthn works - there's no "root credential". See my other reply https://news.ycombinator.com/item?id=17032637
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).
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).
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.
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.
See my reply to your other comment and review CTAP in the spec.
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".
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".
The conversation here is blowing my mind. People are actually worried that their yubikey might get lost or stolen when likely most of your passwords are already all over the internet. I got an email from Twitter just a few days ago stating that they'd leaked my password. Twitter! Not Joe's Auto-Body who's website is being run by a high-schooler, but one of the pioneers of internet companies. They messed up. Your password is not safer "in your head" than a private key because it is not only in your head (who keeps all passwords in their head anymore anyway?)
Private keys are way, way more secure than passwords for that reason alone. You don't have to give anything secret to a third party.
If that's the one problem this solves and revocation and recovery and 2-factor are all still as difficult and broken as they are now with passwords that's still a huge win.
EDIT: more thoughts. 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 (how many of us keep our ssh keys exclusively on hardware tokens?).
Private keys are way, way more secure than passwords for that reason alone. You don't have to give anything secret to a third party.
If that's the one problem this solves and revocation and recovery and 2-factor are all still as difficult and broken as they are now with passwords that's still a huge win.
EDIT: more thoughts. 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 (how many of us keep our ssh keys exclusively on hardware tokens?).
When my password is leaked, I can still access my $important_stuff. When I lose a hardware dongle, I potentially just lost irreplaceable data.
Still reading the comments, but is anyone actually saying passwords are more secure in general? I think most people are saying that they get locked out of their account if they lose the token. How do you validate your account is your account if the only secret you have is lost? If you 100% require a hardware token, you need at least two and/or a method to auth that is not a hardware token so you can recover in a mode where you lost one.
But on the security note. There are several types of security. Security from the people directly around you and security from everyone on the internet.
Without any malware, I could pickup my friends keys and log into their account on my computer in seconds and without their knowledge. This is harder to do with a password. At the same time a password is much easier for someone who doesn't even know who I am to attack.
It's why 2FA is so necessary, it helps defend against both methods of attack.
But on the security note. There are several types of security. Security from the people directly around you and security from everyone on the internet.
Without any malware, I could pickup my friends keys and log into their account on my computer in seconds and without their knowledge. This is harder to do with a password. At the same time a password is much easier for someone who doesn't even know who I am to attack.
It's why 2FA is so necessary, it helps defend against both methods of attack.
"Security from the people directly around you and security from everyone on the internet." Are the people around you not on the internet? They are just a subset of that larger group, aren't they? Sorry if I'm not understanding your point there.
And like I said in my edit, I really hope that Yubikey is not the one and only one way to store private keys. I personally would be perfectly happy, for most websites and apps, to manage keys just like I do for ssh. On my hard drive, backed up to another hard drive or two of mine, protected by a passphrase. I imagine most people would be pretty comfortable letting a service like lastpass manage most of their private keys for them, with multiple copies synced between devices and encrypted with a strong passphrase.
And like I said in my edit, I really hope that Yubikey is not the one and only one way to store private keys. I personally would be perfectly happy, for most websites and apps, to manage keys just like I do for ssh. On my hard drive, backed up to another hard drive or two of mine, protected by a passphrase. I imagine most people would be pretty comfortable letting a service like lastpass manage most of their private keys for them, with multiple copies synced between devices and encrypted with a strong passphrase.
The people around you are (probably) on the internet, but let me try to articulate the threats differently.
If I'm worried about 'people on the internet' that's threats like brute forcing my weak password, or determining my password on one site (through phishing, password leaks, whatever) and trying it everywhere else and finding I reused it; potentially using malware to slurp up passwords.txt from the desktop where I keep my varied passwords. If I keep a strong password for each site in a journal near my computer, I'm fairly well protected from internet threats as long as I don't get a keylogger. If I make sure I keep a copy of my passport journal somewhere else too, I won't lose access.
If I'm worried about people next to me, say roommates, office mates, or any one else who is near my computer, I'm more concerned about the physical security of my password journal; it might not be a good idea to keep it next to the computer if untrusted people will be there. These people could also be looking through password leaks, but they probably aren't.
If I'm worried about 'people on the internet' that's threats like brute forcing my weak password, or determining my password on one site (through phishing, password leaks, whatever) and trying it everywhere else and finding I reused it; potentially using malware to slurp up passwords.txt from the desktop where I keep my varied passwords. If I keep a strong password for each site in a journal near my computer, I'm fairly well protected from internet threats as long as I don't get a keylogger. If I make sure I keep a copy of my passport journal somewhere else too, I won't lose access.
If I'm worried about people next to me, say roommates, office mates, or any one else who is near my computer, I'm more concerned about the physical security of my password journal; it might not be a good idea to keep it next to the computer if untrusted people will be there. These people could also be looking through password leaks, but they probably aren't.
Right. So to summarize, with passwords you worry about people near you and everyone on the internet, and with keys you only worry about people near you.
This is a huge improvement!
This is a huge improvement!
As a security person, would I be happier if everyone switched from password+email to FIDO+email? Certainly.
But FIDO has more competition than that. Since it's not backwards compatible with most existing systems, we have to choose which new protocols to support: passwordless, ssh-like keys, certificates, SQRL, etc. There's limited trust and resources to go around.
But FIDO has more competition than that. Since it's not backwards compatible with most existing systems, we have to choose which new protocols to support: passwordless, ssh-like keys, certificates, SQRL, etc. There's limited trust and resources to go around.
> I got an email from Twitter just a few days ago stating that they'd leaked my password
Clearly you didn't read the email.
The password was potentially logged to twitter's servers in plaintext.
They have no evidence anyone collected those passwords, but various employees could, in theory, have seen those logs.
Presumably those logs are now all deleted.
Even if you didn't reset your twitter password, it's very likely you'd be fine since it's not "leaked" (to the wider internet), but could have been seen by some employees who, for fear of being fired, no doubt did not save it (and in all likelyhood didn't see it in the first place).
Clearly you didn't read the email.
The password was potentially logged to twitter's servers in plaintext.
They have no evidence anyone collected those passwords, but various employees could, in theory, have seen those logs.
Presumably those logs are now all deleted.
Even if you didn't reset your twitter password, it's very likely you'd be fine since it's not "leaked" (to the wider internet), but could have been seen by some employees who, for fear of being fired, no doubt did not save it (and in all likelyhood didn't see it in the first place).
Assume Breach - I read an article about Microsoft's strategy in this regards. Twitter seems to follow a similar model.
https://blogs.msdn.microsoft.com/azuresecurity/2015/10/19/an...
https://blogs.msdn.microsoft.com/azuresecurity/2015/10/19/an...
I think his point still stands. You entrust your passwords to third parties. They don't always handle it correctly.
You obviously are more trusting than I am. Also, my point was that if Twitter messed up, so has every other website. Do you trust them all as much as you trust the Twitter employees?
You don’t trust Twitter’s story but you trust Twitter software engineers more than others?
I trust Twitter’s story about the plain text logging but don’t trust their software engineers more than others.
I trust Twitter’s story about the plain text logging but don’t trust their software engineers more than others.
so basically to defend against password hacking they want to use FIDO/yubikeys.
Too bad if something like twitter happens your yubikey is probably useless after it would've prolly logged anything to their servers.
P.S.: it's possible to change passwords, but hardware keys need to be destroyed and changed. Also Yubikeys can also have bugs. https://www.yubico.com/2017/10/infineon-rsa-key-generation-i... So basically it's not more secure. even worse the more code you throw at a problem the more likely it is to be unsecure.
Too bad if something like twitter happens your yubikey is probably useless after it would've prolly logged anything to their servers.
P.S.: it's possible to change passwords, but hardware keys need to be destroyed and changed. Also Yubikeys can also have bugs. https://www.yubico.com/2017/10/infineon-rsa-key-generation-i... So basically it's not more secure. even worse the more code you throw at a problem the more likely it is to be unsecure.
>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.
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.
Um, if we use public key cryptography, the only thing websites can log or leak is your public key. Since it's public, that doesn't break anything.
accept that your public key is useless if twitter accidently logs challenges.
or even worse your hardware is useless if key generation is too weak.
or even more worse the protocol is so complex that chances are high that even implementations can contain bugs.
or ...
most engineers have trouble implementing simple logins with password. do you really think that having a complex system will be better?
most engineers have trouble implementing simple logins with password. do you really think that having a complex system will be better?
>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.
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.
This isn't a hypothetical discussion. Asymmetric encryption has been battle-tested for decades now. If it's as weak as you say, SSH and GPG would have gotten blown open long ago rather than being the the thing we all reach for when we wanted an actually unbreakable system.
Why would Twitter logging the challenges make the key useless? That data has no value and can't be replayed in a future login attack.
It’s why I told my parents to pick random passwords and write them all down in a notebook that they keep next to their computer. My way, they’re only stealable by their housekeeper or a burglar. If they needed to remember the passwords, they’d be vulnerable to 100 million script kiddies with rainbow tables.
Right. Public key cryptography essentially automates this process that you just described, and makes the security even stronger (because your random "password", AKA private key, stays with you and you only ever share the public key).
>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.
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.
Did they improve the stories for recovery ("I lost my device") and revocation ("my device has been stolen")? As far as I knew you had to buy 2 devices to have a chance of recovery, and Fido 1 explicitly said "revocation is something that needs to be resolved by each website that authenticates users", which is just asking for trouble.
I would love to have a hardware (or even phone-based) alternative to passwords, with no third-party and better privacy, but I feel like this solution only handles the happy path.
For an example of a happy-path-only system that makes me nervous, look at Google Authenticator. Recovery is made with backup codes, but they are also "resolved by each website" (https://security.stackexchange.com/questions/167563/where-to...), which often means no support at all. Not to mention having to create a new backup after creating a new account. I still use Google Authenticator myself, but I dread the day I lose my phone.
If the protocol doesn't handle recovery/authentication, the fallback is a trusted third party (e.g. email) or legal identity (e.g. scanned passport). Aside from being a huge hassle and creating a weak point, it weakens the user's privacy.
I would love to have a hardware (or even phone-based) alternative to passwords, with no third-party and better privacy, but I feel like this solution only handles the happy path.
For an example of a happy-path-only system that makes me nervous, look at Google Authenticator. Recovery is made with backup codes, but they are also "resolved by each website" (https://security.stackexchange.com/questions/167563/where-to...), which often means no support at all. Not to mention having to create a new backup after creating a new account. I still use Google Authenticator myself, but I dread the day I lose my phone.
If the protocol doesn't handle recovery/authentication, the fallback is a trusted third party (e.g. email) or legal identity (e.g. scanned passport). Aside from being a huge hassle and creating a weak point, it weakens the user's privacy.
Neither of those problems (lost key, compromised key) are anything new. Why wouldn't sites just handle them the same way they currently handle revoking/resetting passwords?
Because the current way sucks.
99% of the websites (I have accounts on) rely on my email for recovery and revocation. But my inbox is not an impenetrable fortress, it's a communication channel; every device I own has access to it, and could be used as a backdoor to my entire digital life.
Then there's the risk of the third-party (Google banning me, being hacked, subpoena'd, etc), the privacy factor (see the Ashley Madison leaks), the often custom code implemented by each website...
99% of the websites (I have accounts on) rely on my email for recovery and revocation. But my inbox is not an impenetrable fortress, it's a communication channel; every device I own has access to it, and could be used as a backdoor to my entire digital life.
Then there's the risk of the third-party (Google banning me, being hacked, subpoena'd, etc), the privacy factor (see the Ashley Madison leaks), the often custom code implemented by each website...
> every device I own is has access to it
and this sucks. Why can't I use my google account with my tablet without it automatically getting access to gmail sync?
and this sucks. Why can't I use my google account with my tablet without it automatically getting access to gmail sync?
Every place that I use my key gives you a set of one-time-use recovery codes. To log into your account, you can use either the key or a code. (You still need your password.) Codes can be regenerated at any time. To revoke a key, you simply remove it from your account.
You have to make sure the attacker cannot revoke your key first. If the backup code is unrevokable, then it is indeed a nice solution, albeit a high-friction one if you are doing safe backups for each new account.
They should not do this, as this would make Yubico responsible for potential fraud attempts. Existing sites should do the same way they do already.
It sounds like this is targeted at machines that are attached to Active Directory, in which case the fallback is the same as before (you call a help desk/sysadmin, and they "reset your password" aka verify your identity and give you a new security key).
> I still use Google Authenticator myself, but I dread the day I lose my phone.
I use KeePassXC, and always add the Google auth code to both my phone and KeePassXC, and I back up my password DB (got burned big time there once....).
But yeah, your point is valid. As a tech savvy guy who thinks about this stuff, it's a pain but works. But for most people manually managing and backing up multitudes of keys, passwords, and login data is just so ridiculous a thing to ask that I can't believe it's 2018 and we haven't solved this yet. There must be a better way!
I use KeePassXC, and always add the Google auth code to both my phone and KeePassXC, and I back up my password DB (got burned big time there once....).
But yeah, your point is valid. As a tech savvy guy who thinks about this stuff, it's a pain but works. But for most people manually managing and backing up multitudes of keys, passwords, and login data is just so ridiculous a thing to ask that I can't believe it's 2018 and we haven't solved this yet. There must be a better way!
Re Google Authenticator, as an alternative have you tried Authy? It offers a far better UX, and if you lose your phone you can easily get everything back without doing a backup/restore before hand. Plus you can run it on as many devices as you require, including desktops.
I may be missing something, but Authy seems to me to break one of the main points of 2FA, which is that password breach doesn't give an attacker access to your accounts. If your Authy credentials are compromised, an attacker has access to all of your seeds and can generate codes.
More specifically, they're introducing passwordless login with FIDO2, as Windows had had passwordless logins with certs and CAC cards for ages.
Correct me if I am wrong, but passwordless login is a single-factor authentication and less secure than MFA. Depending on whenever hardware key is more or less secure than the password, the mass adoption of this could make things LESS secure.
> passwordless login is a single-factor authentication and less secure than MFA
If you go from MFA to fido2, maybe. If you go from single-factor password, to single-factor fido2 - it's likely security will improve. A lot.
> Depending on whenever hardware key is more or less secure than the password
It is:
A password can be sniffed, filmed, inferred from sound recording.
You don't know when someone knows your password; a key will be missing (or copied, but that's supposed to be Very Difficult (tm)).
A password is unlikely to encode as much entropy; certainly any password/phrase you actually type in. 128+ bits of entropy is surprisingly hard to encode in a manageable size (it's 16 completely random binary bytes).
Now, if the assumption is that the alternative is a ssh key locked on a device, additionally protected by a pin... Maybe The fido2 is slightly less secure.
But if you try and list the failure modes / do some threat modelling ; I think you'll see it ends up a close race.
It would certainly pair well with "something you know" - eg a pin/password with somehow proper rate-limiting.
If you go from MFA to fido2, maybe. If you go from single-factor password, to single-factor fido2 - it's likely security will improve. A lot.
> Depending on whenever hardware key is more or less secure than the password
It is:
A password can be sniffed, filmed, inferred from sound recording.
You don't know when someone knows your password; a key will be missing (or copied, but that's supposed to be Very Difficult (tm)).
A password is unlikely to encode as much entropy; certainly any password/phrase you actually type in. 128+ bits of entropy is surprisingly hard to encode in a manageable size (it's 16 completely random binary bytes).
Now, if the assumption is that the alternative is a ssh key locked on a device, additionally protected by a pin... Maybe The fido2 is slightly less secure.
But if you try and list the failure modes / do some threat modelling ; I think you'll see it ends up a close race.
It would certainly pair well with "something you know" - eg a pin/password with somehow proper rate-limiting.
I would expect things to be more secure in many cases. People are pretty good at keeping physical items somewhat safe and notice when they’re gone. Yubikeys cannot easily be cloned. The password cannot be attacked remotely. 2FA is certainly safer, though.
Passwords are utterly broken. All the entropy of memorizable passwords among humans have probably been extracted by this point. All they give you is a false sense of security. The password portion of 2FA is mostly theater, conditioned on the notion that passwords are broken. Hardware keys is the way of the future.
Except that passwords at least protect you if your hardware key is stolen. Using just a hardware key seems similarly risky to just using a password.
So in this case, arent the two factors a) physical possession of desktop/laptop and b) the Yubikey ? How likely is it you'll lose both if you keep your keyring with you?
Not sure reading the article why would I need the computer. The way I read it, you enter the key to any computer and it logs in to the account of the key owner. Am I wrong?
FTA: "Organizations will soon have the option to enable employees and customers to sign in to an Azure AD joined device with no password, by simply using a Security Key to get single sign-on to all Azure AD based applications and services."
Emphasis added. Device needs to be paired with Company's AD first.
I also imagine that there are options for making e.g. the device unlock only require yubikey, but login to SSO require 2nd factor.
Emphasis added. Device needs to be paired with Company's AD first.
I also imagine that there are options for making e.g. the device unlock only require yubikey, but login to SSO require 2nd factor.
You can pair new devices with a company's active directory.
The two factors are a) the YubiKey and b) the PIN for the YubiKey.
Your hardware key is in one place, controlled by you. Your password has been leaked all over the internet.
Exactly - It's similar reason to the crypto keys use passphrases.
What you need is a mechanism to detect loss of contact with the human and revoke. One way is to require several hardware tokens to combine their entropy to authenticate. Again, don't make a password be a part of this, use another token.
The standard in high-assurance applications is to present a PIN to the hardware token before it can be used, ideally through an out-of-band keypad.
In this context, it would be reasonable to have the Yubikey require a PIN entry from the computer. You could use the same PIN for all sites because it stays local; the relying party never handles it, only the Yubikey.
In this context, it would be reasonable to have the Yubikey require a PIN entry from the computer. You could use the same PIN for all sites because it stays local; the relying party never handles it, only the Yubikey.
That's exactly how FIDO2 PIN on the new YubiKeys works.
From TFA:
FIDO2 adds more options to the login process:
Single Factor: This only requires possession of the security Key to log in, allowing for a passwordless tap-and-go experience.
Second-Factor: In a two-factor authentication scenario, such as the current Google and Facebook FIDO U2F implementations, the Security Key by Yubico is used as a strong second factor along with a username and password.
Multi-Factor: This allows the use of the Security Key by Yubico with an additional factor such as a PIN (instead of a password), to meet the high-assurance requirements of operations like financial transactions, or submitting a prescription.
It's an option, not a requirement.
FIDO2 adds more options to the login process:
Single Factor: This only requires possession of the security Key to log in, allowing for a passwordless tap-and-go experience.
Second-Factor: In a two-factor authentication scenario, such as the current Google and Facebook FIDO U2F implementations, the Security Key by Yubico is used as a strong second factor along with a username and password.
Multi-Factor: This allows the use of the Security Key by Yubico with an additional factor such as a PIN (instead of a password), to meet the high-assurance requirements of operations like financial transactions, or submitting a prescription.
It's an option, not a requirement.
I think best practice will be that you can login with single-factor and see basic stuff but if you want to do anything more critical like money related or changing email depending from context you are forced to use two-factor.
Also if it's at least approximately to password security this is very welcome options. Most services I use I just want access easily.
Also if it's at least approximately to password security this is very welcome options. Most services I use I just want access easily.
Additionally passwords are protected by the fifth amendment [1]. A hardware key is not.
This is a big part of why you always want one of your factors to be something you know.
[1] https://en.wikipedia.org/wiki/Fifth_Amendment_to_the_United_...
This is a big part of why you always want one of your factors to be something you know.
[1] https://en.wikipedia.org/wiki/Fifth_Amendment_to_the_United_...
In the United States. Maybe.
That is confirmed in the "How does this work?" section. Your concern is addressed in the "Why is this important?" section. The key is definitely more secure against cracking than a password. It is more vulnerable to being physically stolen, but for most people, that is a lower risk.
I doubt that.
Friends or family can't read your mind, but they can steal your physical key.
People putting pins on their phones or password on their laptop are not afraid of being pirated. This is a vague, abstract threat to them. Becoming part of a botnet is really not important to them, and they getting their credit card stolen from the web is really not credible enough for non tech saavy user.
What they are afraid of is other people looking at their stuff. Internet history. Pictures. Their clear text personal document.
Beside, a key is annoying. Where do you think they will store it when they travel ? In the same bag than the laptop. So you steal the bag, you steal the password.
Friends or family can't read your mind, but they can steal your physical key.
People putting pins on their phones or password on their laptop are not afraid of being pirated. This is a vague, abstract threat to them. Becoming part of a botnet is really not important to them, and they getting their credit card stolen from the web is really not credible enough for non tech saavy user.
What they are afraid of is other people looking at their stuff. Internet history. Pictures. Their clear text personal document.
Beside, a key is annoying. Where do you think they will store it when they travel ? In the same bag than the laptop. So you steal the bag, you steal the password.
Friends and family can also steal your credit card, but this is not where the majority of credit card theft comes from.
Your example of people leaving the key with the laptop is a good example of one of the potential flaws, but just like if your credit card gets lost or stolen, you report it and it becomes unusable.
I agree that there is room for 2FA, but this is also surely preferable to the current system.
Your example of people leaving the key with the laptop is a good example of one of the potential flaws, but just like if your credit card gets lost or stolen, you report it and it becomes unusable.
I agree that there is room for 2FA, but this is also surely preferable to the current system.
> Friends and family can also steal your credit card, but this is not where the majority of credit card theft comes from.
This is a false equivalence because knowing someone's credit card data only allows you to do one thing which happens to be pretty detectable: using their credit card for yourself.
Knowing someone's password allows you to know one or more of their secrets, including many applications that are virtually untraceable for the average user. So the deterrence factor is much lower in the second example making it much more likely that a nosy parent / sibling / SO will take a person's key.
This is a false equivalence because knowing someone's credit card data only allows you to do one thing which happens to be pretty detectable: using their credit card for yourself.
Knowing someone's password allows you to know one or more of their secrets, including many applications that are virtually untraceable for the average user. So the deterrence factor is much lower in the second example making it much more likely that a nosy parent / sibling / SO will take a person's key.
You're making the false equivalence.
There's no reason that using a password/key can't be just as detectable as using a credit card.
Also trying to trace logins application side is rather foolish IMHO, this should always be done at the authority that is granting the authorization.
There's no reason that using a password/key can't be just as detectable as using a credit card.
Also trying to trace logins application side is rather foolish IMHO, this should always be done at the authority that is granting the authorization.
> There's no reason that using a password/key can't be just as detectable as using a credit card.
That's not my point. The status quo is that people get alerted if something uses their credit card inadvertently and don't have similar alerts for uses of their password other than in a handful of situations like Gmail logins.
It's definitely not impossible for people to keep tabs on their logins, but this isn't how the Average Joe operates.
That's not my point. The status quo is that people get alerted if something uses their credit card inadvertently and don't have similar alerts for uses of their password other than in a handful of situations like Gmail logins.
It's definitely not impossible for people to keep tabs on their logins, but this isn't how the Average Joe operates.
Switching to a hardware based login system and getting centralized alerts when that login is used is likely going to be the default, not some pipe dream.
Plus, there's also the obvious solution for potentially stolen and misused keys .. just add a PIN.
Plus, there's also the obvious solution for potentially stolen and misused keys .. just add a PIN.
Anyone in the world could crack your password. (Well, any of 2.5 billion people with an internet connection.) Requiring a physical key instead cuts the attack surface down quite a bit. If you can secure your car and house keys, you can secure this.
You use it much more often than those keys. And really people don't care abou being pirated by a stranger. Theyvcare about their spouse leeaning you still talk to your ex. Or your sibling getting a picture of you that is embarassing.
And of course you need a duplucate for the key.
And of course you need a duplucate for the key.
I think you should elaborate on the specific threat model you're describing. Are you assuming a dumped database? Or are you talking about a brute force against an online service?
That is exactly the question a user should ask themselves. I can't answer it for anyone else. But for your two cases, the key is more secure because there is no relatively short password that can be guessed. An attacker has to brute force the cryptographic key, which should be infeasible. Passwords are easier to crack online or offline, unless you've picked a password with 112 bits of entropy.
>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. :)
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. :)
It depends what your threat model looks like.
For example if you have good physical security and limit passwordless login to physically secure machines via AD computer groups, this may protect you from remote attackers.
If however organizations allow the use of this over the internet from "any" endpoint then this completely replaces a password 1:1 and theft/loss of the Yubikey could be a major problem.
This could also be used only on a single layer of your security. For example passwordless VPN authentication but then a password/2F is required for actual user login.
For example if you have good physical security and limit passwordless login to physically secure machines via AD computer groups, this may protect you from remote attackers.
If however organizations allow the use of this over the internet from "any" endpoint then this completely replaces a password 1:1 and theft/loss of the Yubikey could be a major problem.
This could also be used only on a single layer of your security. For example passwordless VPN authentication but then a password/2F is required for actual user login.
Unless you're asserting that the hardware token is just as crackable as a password, it's not a 1:1 replacement. The problem with passwords is that you have 10,000 users and more than one of them has a bad password. The problem with hardware tokens is that I've stolen your token. So passwords are vulnerable to bots, while the hardware token requires a human to find/steal something and connect it with a specific account.
> Unless you're asserting that the hardware token is just as crackable as a password
That's completely outside the scope of what I was describing. You've taken my words out of context.
That's completely outside the scope of what I was describing. You've taken my words out of context.
I'd be open to hearing the right context, since I read it the same way. "Replaces PWs 1:1" is only true in the context of... the attacker only uses stolen passwords and doesn't rely on password dumps? Even in a targeted attack scenario, where the attacker would have to specifically target you to steal creds, this is better, as they'd now have to physically find you and take the key.
[deleted]
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.
The biggest win is that you won't get this email anymore (I got this from Twitter recently):
"We recently identified a bug that stored passwords unmasked in an internal log."
Because all they will have is a public key, not your secret password.
"We recently identified a bug that stored passwords unmasked in an internal log."
Because all they will have is a public key, not your secret password.
You trust a single factor hardware key to protect your car and your home. How often have you lost those?
This is the point that I think too many people don't understand.
If your password is leaked, your username/email has probably been leaked as well.
If your hardware key is lost, assuming it wasn't stolen by someone who has specifically been trying to get your credentials, then there's nothing to tie it to you. You're still going to get a new key and change the locks, but you know it happened.
If your password is leaked, your username/email has probably been leaked as well.
If your hardware key is lost, assuming it wasn't stolen by someone who has specifically been trying to get your credentials, then there's nothing to tie it to you. You're still going to get a new key and change the locks, but you know it happened.
It's too bad sshd never got support for U2F. Seems like the discussions just petered out.
Maybe the introduction of FIDO2 will spark some interest in that again? https://bugzilla.mindrot.org/show_bug.cgi?id=2319
Yes, sure, you could use pam-u2f, but that will never be as seamless as having it supported upstream in ssh.
Or you could use the OTP mode instead, but that has other disadvantages (you have to depend on yubico's servers or run your own KSM+validation servers).
Maybe the introduction of FIDO2 will spark some interest in that again? https://bugzilla.mindrot.org/show_bug.cgi?id=2319
Yes, sure, you could use pam-u2f, but that will never be as seamless as having it supported upstream in ssh.
Or you could use the OTP mode instead, but that has other disadvantages (you have to depend on yubico's servers or run your own KSM+validation servers).
Would be interesting if this would become popular one downside I see to this is that if law enforcement get their hands on your token they can unlock the device.
Also as the token can be regarded as a key rather than a password a court would be able to legally compel you to surrender it without invoking much debate regarding laws against self incrimination (e.g. the fifth).
Can't law enforcement now just ask Google or Facebook or whoever for the information they need without needing your password (or future token)?
It's not that simple, firstly some Google and Facebook services are E2E encrypted which means that they cannot comply.
This also goes well beyond just Facebook and Google and if you use it to lock a physical device like a phone or a laptop that isn't something Google or Facebook would be able to help law enforcement with.
Also while I don't want to make a statement or start a debate on the level of compliance and attitude that Google and the rest have towards search warrants (because it's not relevant and I don't have sufficient knowledge to actually form an informed opinion on the matter). Google and Facebook's legal departments have more funding than most state attorneys yet alone local DA's if they want to fight on your behalf (or on the behalf of their business model) in court they would be able to do so much more effectively than you ever could.
Google and Facebook also require a full and lengthy process with FIDO tokens they can do it on the spot, heck they are legally able to do so if you either agree to a search or law enforcement has an alternative sufficient basis to invoke a lawful warrantless search:
https://en.wikipedia.org/wiki/Warrantless_searches_in_the_Un...
TLDR; Officer: May I search your vehicle You: Yes
At that point they are legally are allowed to take the FIDO token from your keychain and unlock your laptop.
This also goes well beyond just Facebook and Google and if you use it to lock a physical device like a phone or a laptop that isn't something Google or Facebook would be able to help law enforcement with.
Also while I don't want to make a statement or start a debate on the level of compliance and attitude that Google and the rest have towards search warrants (because it's not relevant and I don't have sufficient knowledge to actually form an informed opinion on the matter). Google and Facebook's legal departments have more funding than most state attorneys yet alone local DA's if they want to fight on your behalf (or on the behalf of their business model) in court they would be able to do so much more effectively than you ever could.
Google and Facebook also require a full and lengthy process with FIDO tokens they can do it on the spot, heck they are legally able to do so if you either agree to a search or law enforcement has an alternative sufficient basis to invoke a lawful warrantless search:
https://en.wikipedia.org/wiki/Warrantless_searches_in_the_Un...
TLDR; Officer: May I search your vehicle You: Yes
At that point they are legally are allowed to take the FIDO token from your keychain and unlock your laptop.
So my biggest question here is: Is this Azure only? Each announcement about it seems to indicate that I might not be able to use this key with my local account PC.
Specifically, I have one use case computer where I have no screen, and getting through Windows login without it can be troublesome. I'd love to use this key to unlock it instead, but it's an offline machine.
I had this plan with Yubikey for Windows Hello, which has been out a while, and I bought a Yubikey, and discovered it could only unlock my Windows machine if it was locked (not logged out), which defeated the purpose entirely.
Specifically, I have one use case computer where I have no screen, and getting through Windows login without it can be troublesome. I'd love to use this key to unlock it instead, but it's an offline machine.
I had this plan with Yubikey for Windows Hello, which has been out a while, and I bought a Yubikey, and discovered it could only unlock my Windows machine if it was locked (not logged out), which defeated the purpose entirely.
Unfortunately it only works with Azure (at the minimum AD federation with Azure if you have some on-prem)
You can use other identity providers for Azure AD. Shibboleth is supported, F5 and Ping are certified, there are others. If you use a different LDAP system than AD you can also sync your identities to Azure AD. OpenLDAP or one of the commercial vendors. It might be a little more elbow grease, but it works.
Two things - is there really need for them to be this large? They also look vulnerable? Maybe its just the look, but the blue one looks like it won't survive proper stress test...
And second thing - is exposing connector safe against mechanical damage? Will it withstand constantly being scratched by keys?
And second thing - is exposing connector safe against mechanical damage? Will it withstand constantly being scratched by keys?
There is the "nano" version available which is a lot smaller than the one advertised. The ones that I own have held up just fine for the past year on my keychain.
https://www.yubico.com/product/yubikey-4-series/#yubikey-4-n...
https://www.yubico.com/product/yubikey-4-series/#yubikey-4-n...
This size is much better, but I assume it lacks the "touch" protection against remote attacks, like the other ones?
I still wonder about the exposed connector - what its durability. After all, I would like for such a tool to serve me for years fault-free.
I still wonder about the exposed connector - what its durability. After all, I would like for such a tool to serve me for years fault-free.
I personally have the nano version.
> but I assume it lacks the "touch" protection against remote attacks
It has the touch protection. There is a small strip of metal that protrudes beyond the USB port that you touch.
> what its durability
I've used it daily for about a year. Granted this is not "years" but so far it still feels very solid.
> but I assume it lacks the "touch" protection against remote attacks
It has the touch protection. There is a small strip of metal that protrudes beyond the USB port that you touch.
> what its durability
I've used it daily for about a year. Granted this is not "years" but so far it still feels very solid.
Sounds good then. I am ready to test one of them. Thanks!
Forgive my ignorance, but could you explain what "touch" protection is please?
In order for it to work you have to have it plugged in and touch it. Prevents a virus from talking to it unless it prompts you to touch it somehow.
They’re pretty sturdy. I’ve used my keychain version to pry off beer caps, and it’s gotten some scratches but works fine. The touch sensor is kind of annoying but it does work.
Do previous YubiKeys support FIDO2? From the post, I assume you need one of the new ones.
They plan to support it on "additional keys", whatever that means:
https://twitter.com/Yubico/status/993923882829529088
https://twitter.com/Yubico/status/993923882829529088
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.
The internals probably don't require a form factor that large. Some of Yubico's other products barely protrude from the port. I think there's a convenience trade-off, though...a smaller one is harder to insert and remove.
I have two of this form factor on my keyring, one of which is a couple years old now. Neither show appreciable signs of wear on their connectors beyond what you'd expect from regular insertion. They feel pretty robust, though I've never actually tried to break one...
EDIT: minor clarification
I have two of this form factor on my keyring, one of which is a couple years old now. Neither show appreciable signs of wear on their connectors beyond what you'd expect from regular insertion. They feel pretty robust, though I've never actually tried to break one...
EDIT: minor clarification
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! :)
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! :)
What kind of stress test do you have in mind? I've had a yubikey 4 for almost two years on my keyring that I use daily and despite not taking very good care of it it still works fine. It's been wet, it's been scratched, it's supported the weight of my keys while hanging from a USB port, it's been plugged and unplugged thousands of times...
They're pretty sturdy. Of course if you take some pliers to them I have no doubt that you'll be able to break them in half but for normal use you won't have a problem IMO. The size doesn't bother me either, it's like a very flat USB key.
I also have a nitrokey that's a bit shorter and bulkier and it comes with a cap which might be better to protect the connector, but on the other hand I'm sure I'd lose it sooner or later. A retractable port or something similar would probably be a better idea. Also the nitrokey is significantly slower which is the main reason I only have it as a backup for my yubikey currently.
They're pretty sturdy. Of course if you take some pliers to them I have no doubt that you'll be able to break them in half but for normal use you won't have a problem IMO. The size doesn't bother me either, it's like a very flat USB key.
I also have a nitrokey that's a bit shorter and bulkier and it comes with a cap which might be better to protect the connector, but on the other hand I'm sure I'd lose it sooner or later. A retractable port or something similar would probably be a better idea. Also the nitrokey is significantly slower which is the main reason I only have it as a backup for my yubikey currently.
There are multiple sizes, including ones that barely stick out of a USB-A or USB-C port. The keychain form factor is for convenience. I have multiple keys in multiple sizes for 3 or 4 years now, none fell to mechanical damage (but one pretty much stopped responding to touch, requiring replacement).
They're incredibly sturdy. I don't know what a proper stress test is, but i hung my keys from my usb socket with it, countless times, it's been on my keyring for years, bent and scratched every which way.
Okay, so I have two Yubico U2F keys and two other U2F keys so far. I don't think I'll buy a fifth and sixth anytime soon.
But hopefully U2F will actually work in non-Chrome browsers in the near future.
But hopefully U2F will actually work in non-Chrome browsers in the near future.
> But hopefully U2F will actually work in non-Chrome browsers in the near future.
I would guess you're referring to being able to log in to gmail (or anything in G Suite) with U2F from Firefox.
U2F is already available in the most recent version. See "security.webauth.*" keys in about:config. It just won't work with Google, at least not yet. Google's implementation predates webauth by a pretty fair margin, and from what I have learned, is different in small but important ways from the standard.
So we have a situation that drips irony: we have a U2F standard, usable via a standard authentication mechanism - and incompatible with the very web property that drove the concerted push for the technology's adoption.
I would guess you're referring to being able to log in to gmail (or anything in G Suite) with U2F from Firefox.
U2F is already available in the most recent version. See "security.webauth.*" keys in about:config. It just won't work with Google, at least not yet. Google's implementation predates webauth by a pretty fair margin, and from what I have learned, is different in small but important ways from the standard.
So we have a situation that drips irony: we have a U2F standard, usable via a standard authentication mechanism - and incompatible with the very web property that drove the concerted push for the technology's adoption.
It’s almost as if we shouldn’t deviate from standards just to get features out of the door faster
Isn't it more about pioneering and experimenting in order to inform and stabilize the standards? My understanding is that many new and upcoming protocols are the result of experimentation in the wild. SPDY/http2/quic/etc?
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.
It already works in Firefox (behind a flag), but sadly some websites explicitly target Chrome...
Exactly. In practice it doesn't work. I have a few web sites where I'm using U2F, none of those works with Firefox.
FF traditionally required a plugin, I think native support is recent?
It was added in Firefox 57.
Works fine for me.
Works fine for me.
Can someone remind me why we don't use public key cryptography for authentication on websites?
That's exactly what this is. From the post:
> FIDO2 is built on the same security and privacy features of FIDO U2F: strong public key cryptography, no drivers or client software and one key for unlimited account access with no shared secrets.
They should've kept all the Microsoft stuff out of the post, other than just mentioning that they've been working on the spec together. The Azure stuff seems to have confused everyone about how this actually works.
There are also other app-based ways to login to websites with public key crypto, such as https://www.grc.com/sqrl/sqrl.htm, or https://www.civic.com/. But of course they are less secure than the hardware/Yubikey version, for the same reason Yubikey U2F tokens are more secure than Google Authenticator for 2FA (well, unless companies act stupid and enable "SMS backup" alongside Yubikey support, in which case it's even less secure than Google Auth-only as an option).
> FIDO2 is built on the same security and privacy features of FIDO U2F: strong public key cryptography, no drivers or client software and one key for unlimited account access with no shared secrets.
They should've kept all the Microsoft stuff out of the post, other than just mentioning that they've been working on the spec together. The Azure stuff seems to have confused everyone about how this actually works.
There are also other app-based ways to login to websites with public key crypto, such as https://www.grc.com/sqrl/sqrl.htm, or https://www.civic.com/. But of course they are less secure than the hardware/Yubikey version, for the same reason Yubikey U2F tokens are more secure than Google Authenticator for 2FA (well, unless companies act stupid and enable "SMS backup" alongside Yubikey support, in which case it's even less secure than Google Auth-only as an option).
It looks like there's a W3C draft "in the works" but I'm concerned since almost half the editors work for the two companies trying to pass this proprietary Azure/AD vendor lock-in nonsense.
https://www.w3.org/TR/2018/CR-webauthn-20180320
https://www.w3.org/TR/2018/CR-webauthn-20180320
What is "this proprietary Azure/AD vendor lock-in" that you refer to? How is Azure AD more proprietary than AWS SSO, etc?
You may be comforted by the fact that the top three people on the Github contributor graph[1] are not from those two companies. I've skimmed some of the published meeting minutes[2], and JCJ (Mozilla) and JeffH (Paypal) seem to be highly involved.
[1]: https://github.com/w3c/webauthn/graphs/contributors
[2]: https://www.w3.org/blog/webauthn/2018/01/11/meeting-minutes-...
EDIT: add forgotten link
[1]: https://github.com/w3c/webauthn/graphs/contributors
[2]: https://www.w3.org/blog/webauthn/2018/01/11/meeting-minutes-...
EDIT: add forgotten link
The browser UI is terrible and there's been very little incentive to improve it. The largest user of client-side crypto that I'm aware of is the US DoD with the Common Access Card program, and they just train people on how to use the crappy UI.
> The browser UI is terrible and there's been very little incentive to improve it.
It seems like a chicken and egg problem. There's very little incentive to improve it because practically no one uses it. And no one uses it because it's a bad user experience.
But I would prefer it over using a Yubikey because, IMO, the private key should be associated with a machine, rather than a person. That is, if one of my devices is stolen or compromised, I can use another one of my devices to revoke the stolen/compromised device's access.
It seems like a chicken and egg problem. There's very little incentive to improve it because practically no one uses it. And no one uses it because it's a bad user experience.
But I would prefer it over using a Yubikey because, IMO, the private key should be associated with a machine, rather than a person. That is, if one of my devices is stolen or compromised, I can use another one of my devices to revoke the stolen/compromised device's access.
Because you'd need a cross-platform, cross-machine, cross-device key management infrastructure and browser support that simply doesn't exist.
Even if you contrast it against something like e.g. LastPass or Keepass, you're still missing a ton of infrastructure.
Even if you contrast it against something like e.g. LastPass or Keepass, you're still missing a ton of infrastructure.
Key management.
Beyond what the other comments mention... there's also the fact that most home users only use a single browser, and user account for everyone in the family.
Glad to see greater adoption of Yubikeys, however there is still a long way to go. Speaking from experience writing a u2f_auth client library, browser support is still nascent and hacky. Edge, safari, and AWS would need to adopt it before I would truly consider it mainstream.
If anyone is considering adopting Yubikeys in their organization using a language that is not supported by one of their client libraries my email is in my profile and I would glad to help out to the best of my ability.
If anyone is considering adopting Yubikeys in their organization using a language that is not supported by one of their client libraries my email is in my profile and I would glad to help out to the best of my ability.
I wonder if these Hardware key really make things better for the end-user.
When using it even for login, people connect it to their laptops - that's what most people work with after all - and they must make sure they don't forget it there. As well they need to worry nobody steals it, whether it's on your laptop or you become a theft victim on the street. In the latter case the thieves might know what a Yubikey is and ask you for the pin.
Not sure what problem this solves. But I have the impression we're converting a virtual problem into a physical problem. To be honest I prefer to save keys on laptop drives, that's more difficult to steal, especially when using an encrypted disk.
When using it even for login, people connect it to their laptops - that's what most people work with after all - and they must make sure they don't forget it there. As well they need to worry nobody steals it, whether it's on your laptop or you become a theft victim on the street. In the latter case the thieves might know what a Yubikey is and ask you for the pin.
Not sure what problem this solves. But I have the impression we're converting a virtual problem into a physical problem. To be honest I prefer to save keys on laptop drives, that's more difficult to steal, especially when using an encrypted disk.
No USB-C version and no way to upgrade my other 4+ YubiKeys I've got for more than $50 each! I think YubiKey has been abusing its monopoly recently! They've been working on this for quite some time and clearly new they're not going to make their old premium keys support it so that people can waste time and money to upgrade! Is there an alternative more conscious company - I'd pay even $200 for the piece of mind that I won't have to change this key 1-2 times per year!
P.S. Obviously, no. Neither Nitrokey [0] supports it, nor it's a sturdy one!
[0]: https://www.nitrokey.com/
P.S. Obviously, no. Neither Nitrokey [0] supports it, nor it's a sturdy one!
[0]: https://www.nitrokey.com/
YubiKeys are non-upgradable by design. This is occasionally annoying when new standards come out and you need to go buy new keys (which is not something that's gonna happen a lot), but it significantly reduces the attack surface of these devices. They've been pretty good about giving out free replacement keys whenever major flaws have been found, and webauthn is pretty good about remaining backwards-compatible with U2F keys, so I don't think it's something they handled particularly badly.
I get that, but my point was that they just released expensive new products knowing they'd be obsolete in just a couple of months and people will have to throw old ones in the garbage and buy new even more expensive ones. I do not doubt that a product with an immutable core and mutable interfaces is both possible and even more secure as when flaws are discovered (like last year), some may decide not to replace them - even with free replacement. I spent over $100 just last year, and I think this is a bit too much. I give my old keys to my kids, but, still, I'd appreciate some form of subscription service, which both reduces my recurring cost and possibly improves Yubico's bottom line, too, primarily by building loyalty instead of pissing customers off.
I will point out, NitroKey also doesn't have a USB-C version.
True, nobody seems to offer USB-C. Also, I have to point out that YubiKey 4C [0] is not sturdy either unlike the rest - it disintegrated on my keychain in less than two months without any abuse.
[0]: https://www.yubico.com/product/yubikey-4-series/#yubikey-4c
[0]: https://www.yubico.com/product/yubikey-4-series/#yubikey-4c
Anyone think that Apple is likely to add support for FIDO anytime soon?
My problem is that Microsoft doesn't allow swapping in and out of authentication plugins like PAM.
I work primarily in a Windows shop, and I got the other co-workers in Linux because PAM supports seamless multi-factor auth. I would have went Windows, but its too obfuscated or hard to do that.
LinOTP works very well. And LinOTP works with a wide variety of tokens. Don't be locked to a single vendor.
I work primarily in a Windows shop, and I got the other co-workers in Linux because PAM supports seamless multi-factor auth. I would have went Windows, but its too obfuscated or hard to do that.
LinOTP works very well. And LinOTP works with a wide variety of tokens. Don't be locked to a single vendor.
> Microsoft doesn't allow swapping in and out of authentication plugins like PAM.
FWIW, that's not strictly true. See: https://msdn.microsoft.com/en-us/library/windows/desktop/mt1...
I don't have enough experience to comment one way or the other about its difficulty.
FWIW, that's not strictly true. See: https://msdn.microsoft.com/en-us/library/windows/desktop/mt1...
I don't have enough experience to comment one way or the other about its difficulty.
Well, this certainly surprises me. I know last I looked, there was some discussion about MFA and requiring Azure.
In the environment I work in, I'm not able to use services outside a very limited list, or I have to roll my own using established technologies (FedRAMP). So Azure is right out. So was using Amazon Directory Services.
I know my colleagues are much more familiar with Windows, whereas I.. (look at username, relevant!). My solution, after assessing that Windows couldn't do 2 (or 3) factor, and it was stuck at login/password and some firewall blocking IP's, I knew what I had to do. And that meant Linux for the bastions, and LinOTP and appropriate config options to make it work.
I was kind, and didn't inflict a AAA stack of "kerb, ldap, radius, and shib" on the Windows admins :) Well, that and I didn't want to be the sole maintainer of that system.
In the environment I work in, I'm not able to use services outside a very limited list, or I have to roll my own using established technologies (FedRAMP). So Azure is right out. So was using Amazon Directory Services.
I know my colleagues are much more familiar with Windows, whereas I.. (look at username, relevant!). My solution, after assessing that Windows couldn't do 2 (or 3) factor, and it was stuck at login/password and some firewall blocking IP's, I knew what I had to do. And that meant Linux for the bastions, and LinOTP and appropriate config options to make it work.
I was kind, and didn't inflict a AAA stack of "kerb, ldap, radius, and shib" on the Windows admins :) Well, that and I didn't want to be the sole maintainer of that system.
To be fair, the only reason I knew of this at all is because of a brief patronage of a library in Belgium during a trip I took in the summer of '99. The computer systems of said library used a bizarre system of time-limited authentication tokens stored on floppy disks that were used during the Windows log-on process. I was curious how it might have worked.
You have to write a dll. It's not that big of a deal. That being said, I doubt there's much benefit to it when everything is said and done. (From a windows client perspective.)
"Not that big of a deal." you say? Then why is the documentation how to do this very sparse, and only for Win10? And if it's not a big deal, why is YubiKey making such a big deal?
Well, because in the Windows world, switching in/out authentication subsystems is a arduous task surmountable by primarily Microsoft.
And what would that be good for? Well, simply put would be a nice addition to a Windows Terminal Server. Turn a Windows TS into a proper bastion that requires 2fa. Us Linux admins have that with PAM. Sure would be nice to do the same for Windows. But right now, Windows is grossly deficient.
Well, because in the Windows world, switching in/out authentication subsystems is a arduous task surmountable by primarily Microsoft.
And what would that be good for? Well, simply put would be a nice addition to a Windows Terminal Server. Turn a Windows TS into a proper bastion that requires 2fa. Us Linux admins have that with PAM. Sure would be nice to do the same for Windows. But right now, Windows is grossly deficient.
Back in the Win2000 days, we had GINA[0]; still worked on XP sans fast-user-switching, but killed on Vista+7+8+10 ; The wikipedia page says "credential providers" gives some of the functionality on those OSes though.
I like Linux better too.
[0] https://en.wikipedia.org/wiki/Graphical_identification_and_a...
I like Linux better too.
[0] https://en.wikipedia.org/wiki/Graphical_identification_and_a...
What I'd find interesting is using U2F (or FIDO2, which seems to be an evolution of this) as a second factor for SSH logins. But that doesn't seem possible without changes to SSH itself.
And I hope that this might trigger more widespread support for U2F and similar mechanisms in browsers and websites.
And I hope that this might trigger more widespread support for U2F and similar mechanisms in browsers and websites.
No need to touch SSH itself, PAM is a thing (unless you're on OpenBSD). Here's an example of pam-u2f with OpenSSH:
https://aprilmacdonald.com/two-factor-ssh-authentication-wit...
I actually use a Yubikey for SSH in a different way: with gpg-agent. E.g. https://blog.habets.se/2013/02/GPG-and-SSH-with-Yubikey-NEO....
https://aprilmacdonald.com/two-factor-ssh-authentication-wit...
I actually use a Yubikey for SSH in a different way: with gpg-agent. E.g. https://blog.habets.se/2013/02/GPG-and-SSH-with-Yubikey-NEO....
> PAM is a thing (unless you're on OpenBSD)
And if you are on OpenBSD, there's login_yubikey [0] (although it uses OTP instead of U2F).
[0]: https://man.openbsd.org/login_yubikey.8
And if you are on OpenBSD, there's login_yubikey [0] (although it uses OTP instead of U2F).
[0]: https://man.openbsd.org/login_yubikey.8
Good. After all the roundabout bullshit of "factors" ("2FA") and password managers, people have finally come to their senses that physical tokens are a very natural evolution of analog keys and the only real security, and should have been used from the get-go.
Keys are not the only real security... real security includes something you are, something you have, and something you know.
Having something like this combined with the something you know (passphrase) would be real closer security. Now anyone with your token can access everything that key gets access to, without you needing to be there, or sharing a passphrase. That's less secure imho.
Having something like this combined with the something you know (passphrase) would be real closer security. Now anyone with your token can access everything that key gets access to, without you needing to be there, or sharing a passphrase. That's less secure imho.
A lot of these devices allow you to configure a pin code that is required to unlock the device before use, which effectively provides a second factor. Also, stealing a fido device requires physical theft and can't be duplicated, so the owner would likely know if it was stolen.
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.
Why can't I secure login with a fingerprint?
Microsoft could have team up with Logitech like Sony with Erricson, and come up with a standard and put (mildly cheap) finger print reader on each sold keyboard and popularize open source standard for software implementation.
Microsoft could have team up with Logitech like Sony with Erricson, and come up with a standard and put (mildly cheap) finger print reader on each sold keyboard and popularize open source standard for software implementation.
[deleted]
Your fingerprint is not a key, it's an identity. So your design tells every place you sign in this way "I'm joering2". And if course if any of them want to log in somewhere else, they now know to say the same thing, "I'm joering2".
I guess this is slightly easier than typing your email address? But it's not a security feature.
The FIDO/U2F design is a cryptographic key enshrined as a physical key, so rather than "I'm joering2" it says: "I can prove I'm this particular key talking to your site again using mathematics".
Which key? No way to know, but it's the same one as before. Google can't use the credentials it presents to them to get into Facebook and vice versa, the proof from yesterday is worthless today and so on.
I guess this is slightly easier than typing your email address? But it's not a security feature.
The FIDO/U2F design is a cryptographic key enshrined as a physical key, so rather than "I'm joering2" it says: "I can prove I'm this particular key talking to your site again using mathematics".
Which key? No way to know, but it's the same one as before. Google can't use the credentials it presents to them to get into Facebook and vice versa, the proof from yesterday is worthless today and so on.
This.
Though I'd like to add that FIDO2 does support fingerprints and other biometrics as an additional authentication factor - it all goes under the same abstract "user verification" umbrella as PIN does. The important distinction is that the PIN or fingerprint is never shared with the server - it's only used to unlock the private key - so it's much more difficult to steal.
Though I'd like to add that FIDO2 does support fingerprints and other biometrics as an additional authentication factor - it all goes under the same abstract "user verification" umbrella as PIN does. The important distinction is that the PIN or fingerprint is never shared with the server - it's only used to unlock the private key - so it's much more difficult to steal.
> Your fingerprint is not a key, it's an identity.
Also, you can't revoke fingerprints when they're compromised more than 10 times (20 if you're willing to use your toes too).
Also, you can't revoke fingerprints when they're compromised more than 10 times (20 if you're willing to use your toes too).
I wonder if we’ll get to the point of having two-factor passwordless authentication. Like you need two of the following methods to access a website (u2f/fido2, TOTP, SMS, Recovery codes, tls client certificate, etc.) and forego passwords altogether.
Here is a completely standalone (no server required) and self-contained (no dependencies) FIDO U2F test:
https://github.com/rongarret/u2f-test
https://github.com/rongarret/u2f-test
[deleted]
Can someone explain why CTAP was created? What exactly was wrong / not enough about the original U2F protocol?
I wonder the same. I see the differences in protocols here and there but no fundamental things changed.
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.
- 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.
why isn't a phone with a secure enclave (or similar) the focus, instead of something that doesn't work on mobile?
- 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.