YubiKey 5 Series with New NFC and FIDO2 Passwordless Features
yubico.com
yubico.com
WebAuthn is mostly boring and I think that's mostly a good thing. I'm glad that there's a way to evolve the spec. Some of the changes are arguably improvements; I could see how Direct Anonymous Attestation is better than the old certificate method. On the other hand, that's more exciting crypto than I want to see in W3C specs. But the vast majority of deployments don't care about attestation at all: they just care that you can register a specific U2F key once (say, during employee onboarding), and then you never have to care about attestation again. So other than crypto-nerdery, I'm going to choose not to care much about (EC)DAA.
U2F keys already do WebAuthn (individual sites doing bogus feature detection notwithstanding). Despite the name, at the end of the day U2F is just a way to sign some stuff so that it can't be replayed and you can't get phished. If you really wanted to use it as a single factor, you could.
I'm not sold that the integration of e.g. the browser's password manager into WebAuthn is super valuable, but I'm still happily monitoring what they come up with. That is not a criticism, and certainly not a deprecation. The bottom line is U2F was great, and WebAuthn not convincing me yet is not a good reason to shy away from WebAuthn. WebAuthn is still the best authentication mechanism we (realistically) have by far. Go use it.
Agreed, it looks more like the new keys main draw is feature consistency across the whole YK5 line. You can now select the form factor you want and, aside from NFC, it has the same features as the other form factors. With YK4, there was not nearly the same feature parity across form factors.
It is exactly my case. Also my dongle is already old and its body has abrasion marks due to heavy usage. So, it's a great reason for upgrade and I think I'm not alone in it. Looking forward for available shipping in my country.
I agree that the keys themselves are good; I just wish that configuring Linux systems to take advantage of them would be easier. I've been working on setting my systems up in bits of my free time for more than a month now. I'm in my last stretch, but I have to do some weird things. Maybe I'm just trying to squeeze more out of the key than most would.
For example, when I'm in my laptop and I ssh to my desktop and use sudo, I want it to use the key connected to the laptop to authenticate me. At the same time, if I walk over to the desktop and use sudo, I want it to seek the key in the desktop. Same if I use gpg or anything else that wants to use the key.
As part of this, to make use of the key as transparent to me as possible, I'm finding myself making a compiled executable to override gpg and gpgconf to unshare the mount namespace and bind mount a socket specified by environment variable over the default gpg-agent socket, because there seems to be no easier way to override the gpg-agent socket path via environment variable. gnupg seems to have no such environment variable, and while other utilities query the socket path via gpgconf, gpg itself seems to just know what it is... You know what... I'm starting to realize that's not going to work... Programs that query gpgconf would connect to the wrong agent. I gotta figure out how gpg knows the gpg-agent socket path... Since it doesn't call gpgconf, I wonder if it shares an .o file with it...
This can easily be done, I do it all the time. You have to set up both YKs to have the same PGP keys and then use gpg as your SSH agent.
This effort will also allow me to use gpg and the programs that depend on it like my password manager, pass, to use the correct agent.
It's an -R forwarding what I want. -L would require the host I'm logging into to automatically login back to the host I'm at. That's something that raises way to many convoluted issues. By using -R and ControlMaster, and overriding ssh with one that sets up the forwarding first if the corresponding control socket does not exist, I can share the forwarding among all the ssh terminals I've opened to the same host.
I saw GPG_AGENT_INFO on the manpage, but it says that it's an obsolete environment variable that's now ignored. In my system, gpg2 is a symlink to gpg. I wondered if maybe gpg decided to ignore or use GPG_AGENT_INFO depending on $0, but from grepping the source I don't think it does. It only appears on documentation and automated tests. Still, it might be a good starting point to check the source of gpg 1.4 to get an idea of how to patch gpg2 to get the agent path from an environment variable. Thanks for the help.
EDIT: I made the U2F comment assuming that it works like OTP, but there is some material online referring to it as a protocol using a challenge-response mechanism. If that's the case, what I said would be false. Still, I feel I'm close to an ideal with GPG, so I'm not sure there would be something to gain by using U2F. Unfortunately, most of the material online about it is about using it to login to specific web services like Google.
EDIT 2: I was taking a quick look at pam-u2f[1], and I found this piece interesting:
> manual: Set to drop to a manual console where challenges are printed on screen and response read from standard input. Useful for debugging and SSH sessions without U2F-support from the SSH client/server. If enabled, interactive mode becomes redundant and has no effect.
I imagine this is in consideration with U2F keys that come with a keypad. Otherwise, terminal emulators would have to be extended to support an escape sequence with which it could recognize when a challenge has been presented to automatically pass it on to the key connected.
EDIT 3: Extending my terminal emulator like that and using pam-u2f (after extending it to use that escape sequence) would eventually lead to solving the problem of using sudo remotely. However, going the route of forwarding my gpg-agent also allows me to use gpg (and dependents like pass) remotely. It also seems relatively easier since the only step left for me to figure out is how to get gpg to accept the agent socket path via environment variable.
EDIT 4: On "U2F-support from the SSH client/server", I don't suppose adding an authentication method like that would work when chaining ssh interactively (calling ssh to another machine from a ssh session), like how you can forward ssh agents with -A. I wonder if it's possible to add U2F support to ssh agents. I imagine the agent works on a challenge-response mechanism too, in a sense. Maybe the agent can be made to work like a proxy to the key. That way, -A can be made to work to forward authentication to the key.
On the other hand, NFC is pretty much essential to me for use on an android phone. If this has both then I will look carefully at upgrading.
I'd say YK5 is in "mature"/"stability" product cycle, what means it is good time to buy it whether you haven't yet purchased any MFA key.
(Chrome on iOS works fine with Krypton on the same phone, effectively giving me the SEP U2F I want, just with gross UX.)
Yubico would disagree. According to their research studies BLE devices are harder to use and less robust.
Source: https://www.yubico.com/2016/06/yubikey-u2f-tracking-bluetoot...
Once browsers on Android support WebAuthn, it may well be that plugging in a USB-C Yubikey will be more convenient than trying to locate the position of the NFC antenna.
Financial institution support for phones as the source of the payment tap is spotty here, but definitely growing. Contactless cards are the longer-standing way for Canadians to use this method.
> Like FIDO U2F, the FIDO2 standard offers the same high level of security, as it is based on public key cryptography. In addition to providing unphishable two-factor authentication, the FIDO2 application on the YubiKey allows for the storage of resident credentials. As the resident credentials can store the username and other data, this allows for truly passwordless authentication. YubiKey 5 Series devices can hold up to 25 resident keys. If RSA keys are used, there is a maximum of three RSA with the rest being ECC.
I wonder what the user experience will be like at 25 resident keys, they mention that the YubiKey Manager (ykman) can set/change FIDO2 PIN and reset FIDO entirely, but nothing about managing individual resident keys/credentials.
It seems like it might be a bit challenging to manage this, especially if end-users accidentally register the authenticator multiple times or run out of the 25 slots for some other reason, and be told that they need to reset the whole authenticator and do recovery for all their sites...
https://developers.yubico.com/U2F/Protocol_details/Key_gener...
I'm curious what these resident keys are for.
WebAuthn adds a number of crypto schemes -- to wit, I think they add RSA. You can certainly deterministically generate RSA keys but it's a lot more of a pain in the neck than x = HMAC(k, "u2f" + custom); P = xG :)
It is now starting to make sense to me why. As jiveturkey pointed out, it allows usernames to be stored. And, as you're pointing out, it's useful for RSA or maybe other crypto. Thanks.
That's an implementation detail to support an unlimited number of registrations. FIDO doesn't require derivation this way. Keys can be stored if desired. IMHO it would be superior, given that the device/protocol is designed as a first-class web-aware protocol, not a generic abstraction divorced from the reality of the primary use case. So, given that you are going to use the device with a web browser, the browser should assist you in storing the keys in the cloud. (NB: doesn't have to be and shouldn't be the raw key, it can be sealed by the device or even device/browser combination). This way you have a central location to find all of your registrations and can selectively revoke them easily.
Anyway ...
> I'm curious what these resident keys are for.
It was stated in the parent you are replying to:
>> As the resident credentials can store the username and other data
U2F requires that the server must know exactly which keyHandles to request, based on the username (and probably password) that is supplied earlier by the user, so that the token can take the keyHandle and derive the key.
In FIDO2 "passwordless" mode, there's no username or other identifier presented, so it's just a generic request for credential from the server -- the authenticator has to independently figure out which key to present based only on the origin/domain, and maybe even present a list of stored keys (probably effectively a list of accounts?) to the user for selection. So it'd need some local/resident storage of various bits like the origin, maybe a user-chosen account name, and the actual credential, since it can no longer rely on the server to do store all these bits.
it appears like the only differences between YubiKey 4 and Yubikey 5 NFC is i) the addition of NFC and ii) the addition of FIDO 2 support
The differences between Yubikey NEO and YubiKey 5 NFC appear to be i) The addition of docker login support (?!); ii) FIDO 2; iii) RSA 4096 (PGP) support and iv) ECC p384 (not in PGP) support.
With that in mind.... how widely is FIDO2 deployed? I haven't yet found a two factor app supporting app/site that doesn't support my Yubikey 4.
This raises a more generic question: What's the proper upgrade path for hardware authentication tokens?
This is the reason why I'm still using only a password manager. I agree that a hardware token more security but the lost/stolen/change key problem is really not easy right now.
I hope there will be a new common API to change all enrollment you have done but it seems hard as the key don't even know them.
Maybe in a future version ?
I have a 4C and think it is great - the only downside is the lack of NFC and that only a subset of sites support it, but more are implementing it as time goes on.
I'll probably pick up a 5 as one to store on a keyring for mostly NFC use.
I use four devices regularly: a Windows desktop with USB, an MBP with USB-C, a 6th Gen iPad (Lightning), and an iPhone X (Lightning + NFC).
What I'd really like to see is a small device that lets me use USB, USB-C, Lightning, or NFC with the same token without a handful of dongles to deal with. I get how difficult that is, but I've yet to see anything that supports more than one physical standard. Even USB and USB-C in the same device would solve most of my problem, leaving only my iPad to deal with a dongle due to its lack of NFC.
If you want to give it a try, we'll open source the hardware soon under CC BY-SA. It'd be great to see what you come up with.
How many usernames can a Yubikey 5 remember in the FIDO2 mode? CTAP1 requires no storage beyond a token-wide counter.
Meanwhile telcos are working hard to convince the public they should all throw in with their insecure telecos accounts as a chain of trust after time and time again showing that your telco account is trivial to steal.
Not convinced on FIDO2, either. It means you need TWO of these devices. One as a backup and another as the common case. Why? Because if you lose a single physical key, you'd have to recover your account. Recovering your account will probably end up being insecure SMS auth or easily socially engineered below-US-min-wage outsourced phone support.
This is a race against Mobile Authentication Taskforce and their fundamentally insecure accounts. If the solution can't beat them, it'll get trampled.
Those other "unsafe actors" are trying to completely take over authentication, meanwhile you need 2 $50 hardware security keys at a minimum to safely use this tech. This will lose on consumer pricing and consumer uptake to the insecure Mobile Authentication Taskforce and you won't GET the option to use a FIDO2, because you'll have the choice of insecure mobile auth or nothing.
You have to win against the public or they'll be suckered by bad and insecure authentication that is easier to use, and the things you want to use will be insecure anyways.
Yubico already make a Security Key that isn't also a PGP key store, a TOTP authenticator, bagel toaster and whatever else for about $20. And there are cheaper vendors if price is the main concern.
The argument seems pretty straightforward: if you don’t trust SMS, you need to disable all backup authentication. If you’ve disabled backup, you surely don’t your physical device to be a single point of failure?
It's the backup option, it's the reserve, it didn't have to be the best possible thing, just enough to get you back into the game after you lose the main token somehow.
(And sometime the fine print just seems impractical: I'm unlikely to actually air out my safe for 30 minutes each week, but could replace a desiccant a few times a year.)
Does anyone have a recommendation for a safe that can protect paper documents and digital media from both fire and water in realistic conditions?
Look for UL fire endurance ratings. UL rates them on time and temperature. Edit: I've seen ratings up to 3 hours, but the longer the time, the bulkier and heavier for the same storage volume.
For paper, you'd want something rated to stay below 350 degrees for at least an hour. That's not hard to find even in large sizes. I ended up with a used FireKing 4 drawer file cabinet from a company liquidation sale. Edit: Built like a tank, holds a lot, uses a Medeco key, weighs a couple hundred pounds empty.
For digital, you need something rated to stay below 125 degrees. That's pretty hard to find, and usually only in very small boxes. Unfortunately, some companies (looking at you, Sentry) like to advertise "digital media" boxes which are not rated for 125 when you read the fine print. Not sure how they get away with that. :(
I eventually found a small Sentry chest rated for 125 degrees for 30 minutes. Holds a couple hard drives and some DVDs. Sadly, do not recall the model number. Edit: Storage volume is maybe 5"x5"x8", walls are all 3-4" thick.
I am less willing to use something like this for passwordless logins. These types of devices should be part of the "something you have" part of 2FA, which should always be paired with a "something you know".
Maybe I'm missing a step here, but why would you ever use this for passwordless?
Note that you quickly get to the point where you need more than one person involved. You can compromise one person as much as you want, but if that person doesn't have the complete secret it doesn't do any good.
A fingerprint isn't “something you are”, because it can be destroyed while you remain, and information about it can be captured and reproduced by attackers who are not you.
It's just a particularly hard to lose (but easy to discover, and impractical to replace if compromised, at least more times than you have fingers) “something you have.” In security factor terms, I'm not convinced the idea of a distinct “something you are” category is coherent, since most candidates seem similar to that.
Yes, what I am saying is that in practice what that term of art refers to is not an independent, orthogonal kind of security factor from “have” and “know” but a strictly worse form of “have”.
Much more effective.
I believe this is a bigger barrier for common people who don’t know how to create and retain backup mechanisms. As such, I don’t see a lot of value in recommending these devices to those who aren’t tech savvy without also explaining to them about recovery. So much for technology!
-Static Password
-HMAC-SHA1 Challenge-Response
-OATH-TOTP (Yubico Authenticator)
[1] https://support.yubico.com/support/solutions/articles/150000...
U2F? You need to have a second one or backup codes.
OpenPGP? You probably have your subkeys backed up somewhere so you just order a new Yubikey and put your subkeys there.
The same goes to PIV (X.509 certs). If you have some keys generated on the card, you need to provision your new Yubikey from the beginning.
corollary to this is that you shouldn't ever get only one.
It's also easy to get two yubikeys and have a backup ready to use immediately.
As to U2F, there is always a backup method (usually TOTP generated by Google Authenticator, and additionally recovery codes).
If I get the new Yubikey, my plan is to put the old one in a safe as a backup.
Also, some cryptocurrency wallets, like Trezor and the Nano S, can do U2F. These can be effectively backed up to paper with 12 or 24 word seed phrases, and can serve as a good (if bulky) backup option.
Still, save your backup codes for each site you register.
I primarily use them for u2f and totp, though I want to deep dive into ssh via OpenPgp one of these days. When I want to add a new site, I: 1. Set it up on my keychain key. 2. If at home, set it up on my backup. If not, print out the totp secret on paper and when I get home, add it. 3. Call my parents and ask them to plug the 3rd key into a windows box I can Remote Desktop into and set up either totp or u2f via Remote Desktop. Once done, I ask them to unplug it (it’s attached to the desktop pc case with a lanyard).
I find the “key at parents house” to be really helpful, as if I’m traveling and lose/destroy my keys, I can just call them and ask them to plug it in and then I’m back in business.
Old Yubikeys only support U2F, and there's a Yubico FIDO2 key. Browser support isn't there yet, I've been trying to write a Django library for it but no browser will support the complete FIDO2 flow as far as I know.
Technically U2F can be used to design passwordless scheme too (returning a big array of all key handles known to a service) but FIDO2 probably has some optimizations in this area.
I mean, certificationally, sure. But what prevents a website from trusting you to input your identifier (user name or e-mail address) and then accepting a U2F signed blob as your only credential?
(I would suggest that a single physical device that takes a PIN before it does some signing is still 2FA even if there is only one _communicated_ credential, but I appreciate we need better terminology for this. Other versions of this to consider: if you username + password + Duo into your SSO portal and then sign into a service with SAML, is that not 2FA? If it isn't, does using a session cookie prevent something from being 2FA? For the latter, I'd say obviously not :-) I think the "who can impersonate you" is a good line in the sand, since in the former the SSO system holds full authority in most cases.)
From a Yubico blog post (https://www.yubico.com/2018/05/what-is-fido2/):
> WebAuthn and CTAP2 are both required to deliver the FIDO2 passwordless login experience, but WebAuthn still supports FIDO U2F authenticators, since CTAP1 is also part of the WebAuthn specification.
> Works on Microsoft Windows, macOS, Linux and on major browsers such as Chrome, Firefox, Safari, Edge, and Opera [1]
I looked everywhere for documentation of Safari support but came up empty-handed. Does anyone know where this is documented? I've been waiting for this since forever.
It appears that RSA 4096 keys can be used via NFC, no other NFC-capable keys have this.
One issue is that the algorithms did not change compared to 4. No ed25519, probably due to no tamper-resistant parts with this on the market.
However it is still really nice that it support rsa 4096 over NFC now.
I went with the 4.
The only use I could think of was protecting my LastPass account, but I figured my main risk there is their security getting breached, which Yubico wouldn’t help with.
That said the cheaper yubi do this as well. I use my yubi 4 for securing my ssh key as well though this is a) a pain & b) likely theater.
Maybe I’ll look into a YubiKey though. My problem is that I’m halfway in my own personal transition from USB A to USB C
It's also faster and easier (no pulling out your phone, getting a code, typing it in, just touch the key).
Plus, the keys have other features (GPG keys, etc...) which can be useful.
I personally find the token much more convenient than a TOTP code via app on my smartphone. And the U2F/FIDO part is very interesting as it eliminates phishing as a risk.
I ordered a Yubikey 5 NFC just now to play around especially with the NFC part and see if I can do something useful on my phone with that. I'm still looking for a password manager that could use an NFC Yubikey to unlock it on a smartphone.
AFAIK that's what lastpass+yubikeyneo (nfc) did, and what this should also be able to do.
If you are using additional backup u2f token (2 tokens in total) hacker has chance 1:500 000 to find out correct PIN is my assumption right ?
WebAuthn, U2F and similar FIDO based schemes are sending some public key signed blobs over the network. A PIN is purely a local protection, it's not sent over the wire. So a hacker can't just try guessing the PIN. First they need to steal your physical token, only then could they start guessing PINs for the stolen token.
How does that work? Can't the challenge response be MITM?
I'm not saying it's not impossible, but the it's not the primary attack U2F is designed to prevent.
Works great
[1] https://medium.com/@0x0ece/why-choosing-a-fido2-security-key...
[0] https://www.yubico.com/products/yubikey-hardware/compare-yub... - "ECC applies to the smart card applet only; does not apply to the OpenPGP applet. ECC P256 is the key type generated for the U2F keypair."
They already are water proof and can be run over by a car. So unless you want to take a hammer to it, it should be rugged enough.
The first batch of the 4Cs were notoriously fragile. The plastic would break within a few months of normal use.
USB C has a connector that cannot just be the PCB, and so it needs a housing and such.
The Yubikey 4C nano is hardier than the original Yubikey 4Cs were. I've had mine in for months, and it hasn't broken.
That said, I should note that my laptop (Macbook Pro) also decided to provide insane amounts of power to the USB-C ports on the left side, which fried the Yubikey - literally, there was smoke - and melted the plastic. (That's definitely Apple's fault, though, not Yubikey's fault).
So I would use at least 2, but hopefully websites will allow this, and that will probably be the largest bottleneck in the future. I couldn't care less about "SMS backups" or such nonsense, as that completely defeats the point of using a hardware token. Your account will only be as secure as your phone number is.
Many sites allow this explicitly, and will let you view details about the last time each key was used to log in.
Some sites that use TOTP only allow for one "authenticator" to be configured. In those cases, I scan the same QR code into each key.
This process requires you to retrieve your backup key from whatever safe place you store it in when configuring 2FA on new accounts, but that feels like a reasonable trade-off; I don't make new accounts very often, and when I do I can wait to configure 2FA until I have access to my backup key.