I think the YK5's biggest problem is that the YK Neo and 4, which have been out for years, were already so good. Unless you really care about NFC at the same time as RSA-4096, I'm not sure I see a big impetus to upgrade. Hopefully the USB-C line won't be plagued with supply issues.
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.
> Unless you really care about NFC at the same time as RSA-4096, I'm not sure I see a big impetus to upgrade
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.
> the YK Neo and 4, which have been out for years, were already so good
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...
Do you care if the auth is GPG or U2F? Seems like you want -L to forward a socket, and GPG_AGENT_INFO to point to it. I tweeted this series a while ago because it’s hard to find how that works: https://twitter.com/lvh/status/966408198558244864?s=21
Not U2F because it requires the systems to always have an internet connection. I could setup an authentication server on each machine to avoid that, but I think that would make replay attacks possible (nevermind, see EDIT). Also, since GPG is an option for this, it means that I can just depend on that for absolutely everything. If I break the key in two, I can use an encrypted backup of the GPG key to keep working (authenticating, decrypting, and signing) until I get a new yubikey and write the backup to it.
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.
EDIT 5 (can't edit anymore :( ): I imagine that's what gpg-agent does when working as a ssh-agent, and the ssh server has a public key corresponding to the openpgp card that would be the yubikey. Really, U2F seems to do a subset of what PGP can do.
>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.
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.
That would be enough, if I would compromise to forego use of sudo and relogin with ssh as root. I really would preper to keep the ability to only sudo the parts of composed commands that need it in my non-root shell session, though, which is why I'm still looking into this.
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.
> you really care about NFC at the same time as RSA-4096
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.
The feature the 4 has which the Neo doesn't which matters most to me is 'touch to confirm key operation' when used via USB. I'm quite surprised how little this seems to be known - a hardware key which will sign anything a potential piece of malware or malicious actor asks for without question (assuming said malware is able to steal the PIN or get access to the appropriate agent socket which is not too much of a stretch) is a lesser improvement over pure software keys (sure, you can get the same effect by plugging and unplugging but thats a pain).
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.
This makes sense for enterprise uses where an organization wants to keep private key material off a server, but don't want to spend the money for a enterprise security key manager.
Yes - I'm not saying it shouldn't be possible to configure it that way but it is not great that (at least for OpenPGP) there's no way to set it to require physical interaction to gain access to key functions on the NEO.
Certainly for the OpenPGP applet, require touch to sign/auth/enc was introduced with the Yubikey 4. For U2F touch is always required and you do get an option on the NEO to require touch for Yubico challenge/response. Not sure about the PIV or TOTP applets.
Just wanted to say thanks for these analysis blubs on HN. Whenever something security related pops up, I rest assured that you or tptacek are going to pop in and tell it how it is.
I have an iPhone and a Macbook. It's frustrating that I have to choose between USB-C support for the Macbook, and NFC support for the phone. It's odd that they don't make a USB-C version with NFC.
It's a few months away, but we'll have usb-c + nfc in Solo (open source security key supporting FIDO2). We'll launch the Kickstarter next week: https://solokeys.com
We're starting FIDO2/U2F only, but we'll have the possibility to upgrade the firmware. PGP/SSH are the top feature requests, so we'll add them right after the Kickstarter -- unless the community builds them first.
Ciao Emanuele, just dropped a linkedin connection request. I am working on a product that would benefit from solo, would love to pick your mind sometime in near future.
Because one day we'd like to securely authenticate to things on phones in phone browsers. (I agree that it's not a big a deal as one may think; it only matters if you're logging in to a critical service via the browser and not the app. If you're using the app, it's the app's problem to make sure that you're talking to the Correct Service(TM), so phishing concerns go away.)
Contrary to (at least the 4 series-era) Yubico's marketing materials, their Android app works fine with USB (in fact better than with NFC), so if you have and Android phone with a USB-C port, you can plug in a USB-C Yubikey directly (or a USB-A Yubikey with an adapter).
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.
Anyone who routinely uses tap-to-pay will already know how to position their phone for NFC functionality. Here in Canada, support for tap-to-pay in point of sale systems is near-ubiquitous. Not 100%, but it's it's very much the exception for it not to be supported.
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.
BLE solutions are going to work much better for mobile devices than NFC I think. Google already supports it for their apps via SmartLock and Advanced Protection on both major mobile platforms. Its the browsers, and namely Safari, thats being the blocker on iOS right now - both for NFC and BLE solutions.
It works in iOS Chrome but only on Google properties. I agree Safari is a problem, I’m not sure it’s the only pinch point. They managed to glue it all together with app links and URL schemes.
(Chrome on iOS works fine with Krypton on the same phone, effectively giving me the SEP U2F I want, just with gross UX.)
That makes sense. I generally don't use my phone to log into anything that requires 2FA, so that didn't even occur to me. For whatever reason, most of the services I use that require 2FA tend to be pretty useless on mobile web.
Just to warn you - although you can put Yubikey 5C on a keychain, it's not robust, and the plastic disintegrates after light use in just months. I had two that got destroyed. Unlike the USB-A, which are highly resilient to wear, the USB-C version are greatly subpar! Given how expensive this is and how important is, it's highly disappointing that they didn't put more thought into the material selection process! Or maybe that was the main idea - make you buy a new key every year.
Just so you know - I had the same problem but emailed Yubico recently and they said they made some changes because of this defect and sent me a new one for free. It's been at least 2 months and there's been no degradation like my first one.
Thanks for the info! I'm glad that fixed this. I will reach out to them today as I migrated off the old key long ago. If they replace it, I will give it to my 10-year-old son, who uses my old keys. :)
> 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...
> keys are not stored but rather regenerated with an HMAC
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
They continue doing the key wrapping with HMAC for U2F. Resident keys are for the "passwordless" authentication method under FIDO2.
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.
The spec doesn't insist on it, but that's how Yubico devices do it, yes. It's the straightforward thing to do when your scheme eventually relies on ECDH and there's an obvious and performant way to go from a base secret to a specific-use secret (via a KDF, here HMAC) to a public key (via scalarmult). It'd be less straightforward if your key generation is expensive and complicated.
If I'm understand correctly, the resident keys can be used in the case of a non-ECDH scheme and otherwise they wouldn't be used? How flexible is the FIDO2 specification on crypto schemes?
I don't understand what you're saying. Which resident keys?
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 :)
In the parent comment link to the technical manual it mentions 25 resident keys can be stored.
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.
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.
U2F over NFC works on the NEO; I've been able to login to GitHub through Chrome with the Google Authenticator Android app. Same with Google account login on Android when adding an account to the device
The neo doesn't do totp at all (nfc or otherwise). It will do hotp, fixed response, and a challenge-response mode over nfc. It might do more but I haven't used them. I'm currently using the challenge response with keepassxc over USB and keepass2android over nfc. It's been working great
Now I've only got one problem remaining: how do I upgrade my old U2F-capable NEO on all the websites? Do I have to keep it with me ad infinitum? I cannot really destroy it either, as I cannot be 100 % sure I've remembered to enroll my new Yubikey 5.
This raises a more generic question: What's the proper upgrade path for hardware authentication tokens?
> 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.
It is annoying you have to choose between USB-C and NFC. I was really hoping I could have both in a new device.
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.
Just replied in another thread: it's a few months away, but we'll have usb-c + nfc in Solo (open source security key supporting FIDO2). We'll launch the Kickstarter next week: https://solokeys.com
Interesting. This solves about half of my problems.
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.
As of today most people seem to want a hole to attach it to a keyring. So it's kind of hard to have even usb-a on one side and usb-c on the other side. Let alone lightning.
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.
Will it have all the features of a Yubikey? I have two YubiKeys right now. One with NFC and one USB-C. I would love to just have one, and open source is a plus. I also use the NFC one for 2FA code storage. I then can use my laptop or phone to retrieve a code.
Not at the beginning. We're starting FIDO2/U2F only, but we'll have the possibility to upgrade the firmware. PGP/SSH are the top feature requests, TOTP we'll have to look into it, if the way yubikeys are doing it is open, we're happy to be compatible.
Sounds interesting, the big thing for me is GPG support though - U2F is actually my secondary use case. Working on plugins is good, but I'd want to know it was equivalently useful for me.
Is there an "explain like I'm 5" intro to FIDO2 that explains how FIDO2 as the single factor is more secure than the user entering username (not password) and then using a CTAP1 token? (Also, how do you log in to multiple accounts on the same service with FIDO2?)
How many usernames can a Yubikey 5 remember in the FIDO2 mode? CTAP1 requires no storage beyond a token-wide counter.
We'll see. There was barely any uptake of FIDO U2F on the web. Sure there were a few major players, like google, but pretty much nothing financial for the public have taken up anything but insecure SMS/call authentication.
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.
Some actors doing unsafe things should not preclude us from building safe things in the mean while. Google/GSuite accounts matter. GitHub accounts matter.
The problem is that if poor solutions as far as usability are present, you'll have the telecos win.
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.
You don't need $50 products. You especially don't need two of them.
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 $20 one doesn't support a phone, regrettably. We need at least the $45 NFC edition, or it won't help people trying to log in with their phones. We continually talk on HN about how many are increasingly only using their phones and no longer use or posses general purpose computing devices. A USB-A only device only works for people still using computers. The Mobile Authentication Taskforce still wins and your only choice anywhere that isn't already highly technical will end up being Project Verify and the point of failure will still remain as socially engineering underpaid customer support staff.
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?
My point was that your backup "emergency" token doesn't need all the fancy features of the 5 series.
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.
I use the yubikey for OpenPGP (with SSH) and I took care to generate the keys on my computer then back them up appropriately. I can restore to any new yubikey quickly (tested).
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).
Yes, and it's by design. If you could then one random root key would be sufficient to "restore" all keys (as they are derived from that root key). U2F explicitly doesn't allow that given that the protocol has use counters.
For 2FA, having multiple of these or some kind of recovery code tends to be the answer, as you can remove the keys from sites you use it on.
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?
For U2F you're right that it becomes single factor if you use the device as the only factor. With FIDO2 (which is what makes passwordless available), however, the device supports a local PIN as the "something you know" factor - and it's also a better kind of knowledge factor than a traditional password since it's never sent over the network.
it is a different level of security. The comic is fully correct, but you should still use a secret. That is why there are 3 different types of authentication. The first is something you have - a card or key. The second is something you know - a password. The third is something you are - a fingerprint. Each provides protection against a different attack and is vulnerable to different attacks. The more important the secret the more of them you should use.
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”.
The reason DNA is useful as criminal evidence is you leave it everywhere; that makes it a horrible security factor: like fingerprints it's an impractical to replace wheb compromised “thing you have” that you leave everywhere for attackers.
That is a very good reason to not use it alone. However when combined with other it provides a good indication that someone was actually there. Either that, or the attacker went through more effort to get the secrets.
Calling a fingerprint "something you are" is a stretch. You are leaving fingerprints everywhere, they can be lifted from any smooth surface you touched (or even high-resolution photo) and then used to open biometric locks.
The fingerprint belongs to you. Calling it 'something you are' is conveying this, without claim to it being somehow difficult to clone or entirely unique. Mother's maiden name is similar in this regard.
It’s worth knowing that krypton (https://krypt.co) can make your smartphone act as a U2F or Fido2 (as well as SSH and PGP) device. You can use this instead of a Yubikey, as a backup, or just to inexpensively play with the concept and test out your backup protocols.
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 actually have 2 Yubikeys, one with me, one in a safe place. But the price of these keeps rising. $50/$60 is starting to get a bit unreasonable for something that you were able to buy 2 or 3 of for the same price a few years back.
I do the same thing, but my backup device is stored off-site, so it's pretty hard to make sure the backup device is connected to the same accounts as my primary ones. I currently keep a list of new accounts I've added and then periodically retrieve it and add the new accounts.
You should have backup 2FA methods for that case, either more tokens at different locations or other 2FA methods like TOTP or printed one-time backup codes or all of these together.
I say take a morning and print out all your one-time recovery keys, put them in an envelope, and put that envelope next to your other important but rarely used documents.
Off topic: I feel like a fireproof document safe is something that I should own, but every time I shop for one I find myself going down a rabbit hole of unfamiliar terminology and certifications. As with many things, it seems like the marketing for such safes doesn't always match the fine print.
(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?
I don't have a specific recommendation, but suggest you don't try to combine the paper and digital requirements.
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’ve had the same concern for a long time, but more from a worry about what to do when it breaks or stops working after a few years. The recommendations I’ve read are to always have a recovery key or other alternate mechanisms that don’t depend on this device. One common suggestion also seems to be to print the recovery/alternate key and keep it safe.
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!
It's smart to buy two at the same time. While you can't copy a Yubikey, you can choose how to initialize them and you can initialize both identical to one another and then lock them down. That way they're copies of one another and fully backed up. I keep my main one on me at all times and have my backup in a safe place.
It works very well for TOTP, just initialize all the keys at the same time. You can also print the qr code on paper as an additional layer of backup which makes it easier to add a new key if you destroy yours. Obviously if it was lost, you’d want to invalidate that and reset it up, but if run over by a truck and you’re holding the pieces, it’s easier than setting up all of them again.
IMHO the YubiKey is not useful for any of those. It's excellent for storing OpenPGP keys and U2F, reasonably good for X.509 (as much as expected for X.509 I guess), and not good for much else. Using it for TOTP IMHO makes no sense, it's better to use your phone.
Authy is excellent for this. I've got it on my phone and tablet. I'm reluctant to use it on my desktop because I don't want to type in a huge password but I regard my 2015 MacBook as less secure than my devices that are protected by touch. You might be OK with that or have a laptop with touch ID.
I keep 3 keys active. One is on my keychain, one lives in a locked file cabinet in my home and I have one at my parents house on the other side of the country.
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.
I have a basic Yubikey (USB only) that I got from having an Ars Technica subscription. Right now I have that + Authy so that none of the critical services are Yubikey-only.
If I get the new Yubikey, my plan is to put the old one in a safe as a backup.
I bought a yubikey 4 a while back and thought the same thing so I never really used it. I might use this as an excuse to buy another yubikey and have one as a backup.
I'm a LastPass user using Yubikey nanos for both my work and home PCs. But I would like to purchase a Windows 2-in-1 that only has a single USB-C port used for charging and thus a nano wouldn't really work out well. Since Yubikeys, including these latest 5 series, do not support bluetooth, most Windows laptops don't support NFC, and LastPass does not support FIDO/U2F (so Google's Titan bluetooth won't work), is my only option to unplug the charger, plug in the USB-C Yubikey, and plug the charger back in every time I want to log into LastPass? I'm kind of an end user with this sort of stuff...
SMS as a 2FA method can't be disabled for Duo administrators. Sim takeover or GSM sniffing attacks can take over the whole account. Mentioned this to their support many times. They don't care.
I tried the Duo integration and I’m not a fan. It didn’t let me set up more than one key and it wasn’t as easy to use as Google’s Smart Key app/Chrome integration. I disliked Duo integration so much it had me searching for alternatives to LastPass though everyone else uses Duo too.
The difference between WebAuthn and U2F isn't really clear to me, but I hope the older generations will continue to work with common browser's FIDO2 implementations for a long time to come. YubiKeys are great, but too expensive to replace on a whim every year.
U2F can only be used as a second factor. FIDO2 can be used as a replacement for a username/password, so you can go to a site, insert your FIDO2 key and log in without any other information.
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.
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?
It's not built into the protocol, sure, but the device can do whatever it wants before it decides to sign something. You need to unlock my phone and SEP before Krypton signs anything, for example. But you still raise a good point: I suppose it's a good thing that we can do that with cheaper devices and safe, browser-provided UX for PIN entry.
(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.)
I completely agree with everything you said, but a U2F token that takes a PIN would be hard in the sense that it would be hard to make it cross-platform (unless the PIN pad were on the actual device or something).
> FIDO2 can be used as a replacement for a username/password, so you can go to a site, insert your FIDO2 key and log in without any other information.
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.
WebAuthn is backward compatible with U2F tokens, but naturally only for use as second factor. They defined CTAP1 as the U2F protocol for existing tokens, then defined the new CTAP2 for communication with the new tokens, and made both part of the spec.
> 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 should also work with Vivaldi (From the makers of Opera) and tries to make a more modern Opera 12. Vivaldi uses chrome extensions. I still see some people using Opera and they never switched to Vivaldi.
That happens to be the very browser I'm using now, but Vivaldi support doesn't surprise me, given that it's built on Chromium. I love Safari and will continue to use it every day, but the previous (?) lack of U2F support was (is?) a drag.
Wow, this looks really cool. Yubikey 4 lacked NFC support so with 5 it's easy to use the same key via USB-A (laptop) and NFC (via OpenKeychain on Android).
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.
I’ve always been fascinated by these, but never had a justifiable reason to get one.
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.
I have one of the old blue U2F tokens (~20 EUR), and pretty much only used it for GMail so far. That alone is worth it to me because many other passwords can be reset by someone that gains control over my email account.
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.
There are Password Store app for Android (by Zeapo). It can be interfaced with OpenKeychain in order to use NFC key. So I think you will be able to achieve full-featured OpenPGP encryption for your passwords using external hardware key.
The browser sends the domain as part of the request to the U2F key; so a MITM would need to be a true network-level MITM and not just a fake website MITM. The user would then have to ignore the cert error as well.
I'm not saying it's not impossible, but the it's not the primary attack U2F is designed to prevent.
well code which U2f token generate with the help of Google authenticator has ONLY 6 digits. 6 digits that's not extremely hard to brute force is that right ?
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 ?
You seem confused. I think you're describing TOTP, but this whole thread is about FIDO.
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.
App based 2FA is still more vulnerable to phishing than a U2F key, because it relies on the user to check they are entering the code into the right website.
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.
Unlimited! Except for passwordless credentials, which do consume storage space aboard the device. But second factor (U2F style) credentials are stored encrypted on the server, so there's unlimited "space" for them.
I'd be more concerned about general reliability. How long will these last? Because I think they should last at a minimum 10 years. If you only use one for an account, and it breaks on you, you're screwed.
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.
I configure a second YubiKey as a backup, and disabled SMS-based recovery where possible.
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.
> I was unaware, but I guess that sorta makes sense. I have only done with USB A style, which is an Epoxied PCB which makes it fairly hard to break. 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).
I've had my yubikey 4 nano for a year now. I have it on my keychain and it has weathered much abuse. it has a few scratches but that's about it. it's a very durable thing
I just tried to order one. My credit card got charged twice as I attempted twice, got errors on their website, and the customer service rep Rachel in the online chat is behaving highly unprofessionally. My other attempts with another card were flagged as a possible fraud - obviously, their reputation among the credit card processors is not stellar. I think I'm done with Yubico and will be waiting for my Titan key from Google and consider the open-source SoloKeys as well. I think I've invested enough money in Yubico and what I'm getting back is not enough to justify the costs of this luxury. Their shortsightedness not to offer NFC on the USB-C version and to make the 4C/5C Nano so extremely hard to pull out is a clear sign they no longer are a good choice. And for quite some time, they haven't been the only choice either.
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.