An Opinionated Yubikey Set-Up Guide(procustodibus.com) |
An Opinionated Yubikey Set-Up Guide(procustodibus.com) |
I don't generate my keys on devices. That lets me be flexible and keep backups, as well as use the same keys on multiple physical devices. Using a single yubikey is a bad idea, as you're bound to eventually lose it or break it. Hasn't happened to me yet in 5 years, but I expect it to happen.
I wish more sites supported hardware keys instead of only TOTP tokens, or (heaven forbid, but corporate idiocy is plentiful) SMS.
Besides, 1Password now has a very convenient agent, which prompts users permission for an application to use a key - which is added security https://developer.1password.com/docs/ssh/get-started/#step-4...
And yes, Yubikeys do break - My keychain'd 5Ci is missing a huge chunk of plastic, exposing the PCB, and among the two new C Bio I received last week, one has already fried after just a few days.
I love my Yubikey - it’s way less friction to use than other forms of 2fa, and I get to use it for stuff like storing my PGP keys. I don’t feel like it use it to its full potential (mostly signing commits and ssh) but it’s super satisfying seeing that little “Verified” badge next to my signed commits :)
I use it daily for Github/ssh in general - and the 2 slots are used for part of passwords for a couple of other things.
I have a couple that are used daily, one in a safety deposit box (which is the "master" key), and a stack of new ones on my desk in case anything breaks. (I used that Cloudflare offer to get a hefty discount on them).
I also have a paperkey copy that lives elsewhere.
If you set all this up, then it would be an expected outcome that the most likely thing you'll be doing is needing to recover from a disaster, not prevent a compromise.
It took a little effort to set up, but now it's working as intended. And I didn't realize it, but every time I had to pull out my phone and enter one of those stupid 6-digit codes, I was grinding my teeth! It was just such an annoying little chore. My mouth feels so much more relaxed now that I just tap the little button on the Yubikey.
I also set up the long-press functionality to store a static password, and that has been the cherry on top.
You can solve most of those with only FIDO2 nowadays:
Webauthn with fido/u2f is supported on most websites and oidc providers.
SSH with FIDO and resident / non-resident keys is supported.
PAM -> as documented in the guide, although setting origin and type manually isn't necessary and you can save keys in ~/.config/Yubico so non-root users can manage their keys. I would recommend enabling PIN verification with pamu2fcfg --pin-verification.
LUKS hard disk encryption with FIDO2 for unlocking isn't covered but is possible, systemd-cryptenroll can set this up on modern linux distributions.
I wish that was true. I’ve found that webauthn is becoming more common in the last year, but is still relatively rare. Many “important” sites and services make use of them. https://www.yubico.com/works-with-yubikey/catalog/ is a great place to see them, but they’re still quite rare as a whole.
I recommend getting 5 Yubikeys, generating unique PGP keys on all of them, then storing two offsite in different locations, such as your vacation home or safe deposit box or office. Three are for your keychain and one each for your desktop and laptop or two laptops.
Then, PGP encrypt your text file with all of these details to all five keys.
I have two Yubikeys (a primary and a backup) in each of two safe deposit boxes in different states (4 total), one on my keychain, and one nano in each of my 5 computers. I encrypt my long term data to 10 recipient keys.
- Model: Ideal device is 5C.
- GPG: S key should not also be C. The point is the C key should be the root of S, E, and A so they can be expired, revoked, and rolled individually.
- NFC: Disable it or don't buy it. It's a wide attack surface. USB-C works with iPads and Android devices, iPhones <= 14 with an adapter, and iPhone >= 15.
- Backup & recovery: Contrary to YK doc, there are too many issues with multiple card-generated YK secrets and identifiers for practical use. Create an identical device (apart from card no) with a 2nd YK kept offsite in secure physical storage by loading secrets to both rather than generating them on-card. It's possible to do so securely on a trusted machine (say running Tails or Qubes OS on a physical new machine without internet).
- Reset PIN: It's foolish to not create one.
- FIDO2: Setup your own (deprecated but still works) private, firewalled behind NAT server from https://developers.yubico.com/u2fval/
- Linux and Mac workstations: Setup gpg-agent ssh-agent compatibility instead of the PIV method because it doesn't require their custom PKCS#11 module with an unproven security track record. And update the firmware with the Yubikey Manager app.
I want to be able to have Yubikeys for (i) my primary desktop at home, (ii) my travel Laptop & other devices (iii) backup (at least two) if any of the primary ones fail. Rinse and repeat for each family member.
Their FIDO U2F costs only 5 euro.
Now I can say to people I talked to that they no longer have any reason not to use security key.
https://www.token2.com/shop/product/token2-t2u2f-security-us...
> The best back-up is the buddy system: make sure at least one other person has an equivalent set of credentials for every application for which you use your YubiKey.
Why is this the best option? How is it even a good idea at all? We're talking here about someone you deeply trust, I assume? I have a second Yubikey which is accepted everywhere my primary Yubikey is. Why is that the second-best option and not the best option? I must be missing something basic here. Can someone help me out?
Seems like this advice assumes you're using your Yubikey to protect data you want to outlast you?
Can't stress this enough. I had a yubikey nano that I literally never pulled from my laptop, that sat on my desk for basically the entirety of COVID. It just up and died after about 14 months. Fortunately, I had only set it up for testing purposes because I was worried about this exact scenario, and while I had a backup in my safe, had I been on my normal travel schedule that wouldn't have helped much.
The fact that it died after 0 abuse was a MAJOR turnoff for me ever proceeding down the path further. I'm sure my failure was a one-off but it left an extremely bad taste in my mouth.
I get a failure of a key that's on a keychain or being beaten up on the regular, but failure from literally just sitting in a usb-c port for less than two years is... not a great look.
I guess this might be an expected failure mode too, because their warranty is only 1 year for manufacturing defects.
Backup is a serious question though. I once started down this rabbit hole trying to type up a guide for using my yubikey and I found myself giving up when I realized there was no perfect solution.
This is the same for encryption: the number 1 threat is lost encryption keys; the number 2 threat is broken backups; the number 3 threat is stolen encryption keys. Having #1 occur is equivalent to being ransomwared with no way to pay.
In both cases, you need multiple copies, or if you are using non-copyable aspects of security keys like U2F or OTP, then you need multiple backup keys registered to the same services.
The yubikey ends up being solely for convenience for less important things(it's easier to press the yubikey physically than it is to bring out my google authenticator app and copy/paste a TOTP).
Agreed that the article goes into extreme technical depth from a security/cryptographic perspective, whereas losing/breaking/being_stolen is actually the vastly more likely scenario.
This is so true. I worked on v1 of BitLocker. Key management was a much bigger feature than the actual full-disk encryption. I only recently got a Yubikey because I know how easy it is to shoot myself in the foot, and I’m still very nervous about it.
https://www.jabberwocky.com/software/paperkey/
https://wiki.archlinux.org/title/Paperkey
gpg --export-secret-key $KEY | paperkey --output-type raw | qrencode --8bit --output $KEY.png
zbarcam --raw --oneshot -Sbinary | paperkey --pubring $KEY.gpg | gpg --import
The article even actively suggesting you DO NOT make backups of things.
Now you’re ready to generate a new set of OpenPGP keys on the YubiKey, using the generate command:
gpg/card> generate
Make off-card backup of encryption key? (Y/n)
Enter n to ensure that the private keys never leave the YubiKey, and enter the admin PIN when prompted:
I usually don't go through quite so many steps, so if my machine was already actively compromised when I generated my keys, then the attacker has my keys.
If you're all in on the idea and have a robust process around key custody it's great, but if you just deploy it without thinking especially to an environment that may not be fully rebooted for 1-2 years at a time, it's far more likely someone will lose the keys and then only months or years later when the entire thing is restarted realise they lost all their data. And I'd put this as more likely than encryption at rest ever saving most people from data privacy.
You have to include availability and user experience in your "threat model".
99% of users are probably better served by Tarsnap and its ilk than attempting to roll this kind of thing themselves.
I tested the personal key pair first. The primary yubikey I had on my (physical) keyring failed spontaneously after less than three weeks of being carried around in my pocket. That was the end of that.
I am not going back to physical tokens, except for RSA tokens and purely mechanical keys. Those have an adequate track record.
One of them is a black one that work gave me for use with the work computer. I’ve had this Yubikey for over 1 year.
Three of them are blue ones I bought from Amazon, that I also added to my SSO profile at work. I’ve had these Yubikeys for several months.
One of them I keep in my wallet most of the time. One of them I keep on my desk and bring in my backpack when I go somewhere. One I keep in a box. One is somewhere in the room.
I rotate between these, and I switch which one I keep in the wallet, which one I keep in a box etc.
It’s worked well for me so far. None of them have failed yet, and when one does fail or get lost I will remain confident that the other ones I have will continue to work long enough that I can order even more Yubikeys to replace which ever ones went bad.
For me the track record has been perfect.
Heck, even the idea of having to renew your resident GPG keys is a nightmare, let alone in different states. If you even let your master key expire on the device, you won't ever be able to renew it or it's derived SSH keys, and will have to reset the device. That's not to mention fried keys, stolen keys, etc. Consumer-grade vaults can be picked in minutes, and most large banks do not issue new deposit boxes anymore.
Any paranoid/sophisticated users would be more than happy with having their SSH keys in 1Password & using their agent, or having one key at home w/ home alarm, one key on them.
You seem to misunderstand me.
They're not in vaults for protection from the government; the state can access them at will. They are in vaults for fire safety.
They are in multiple states for safety against natural disasters. If one bank floods or is destroyed, a copy exists elsewhere.
Each vault has two Yubikeys, to protect against fried keys. Two locations in case one is stolen, etc.
It's not about threat model, it's just about DR.
> Any paranoid/sophisticated users would be more than happy with having their SSH keys in 1Password & using their agent, or having one key at home w/ home alarm, one key on them.
Storing the keys in software makes them vulnerable to software malware, which is ridiculously common. No "paranoid" required.
Most people are at home most of the time. If one key is at home and one key is "on [you]" and your house burns down, you lose all your keys and all your data so protected.
It's not some state-sponsored attacker that requires you to keep an extra key offsite in a fireproof room.
Most people don't have a vacation home, or a safe deposit box. I didn't even think you could still get those at most banks. Plus, I suspect most security conscious people would not want to leave anything at their office.
You can leave them at friends houses, but that's not exactly always a secure location.
Phone numbers can at least theoretically be recovered, so my unpopular opinion is that SMS is pretty great for personal stuff.
I don't lose keys.
When I get new accounts, I simply enroll each of the keys in each computer, plus my keychain key, in the U2F for the new account. This doesn't happen often due to SSO.
That's good enough for my personal life. I only use a key at work, where they manage all that for us.
I've yet to test this but adding a hardware key is the advice I've found online around this particular issue.
(Yes, I also have my own domain in the case I get fully locked out, I am paranoid)
So you don't need the expense of buying multiple yubikeys if most of them will end up in safety deposit boxes. Just put a printout of a TOTP QR code in the safety deposit box.
(This doesn't apply if you want to use the non-U2F features of the yubikey, like PGP, but who needs that?)
Next, use 1password with the family. It too has FIDO support.
I'm not really that concerned about someone gaining physical access to my system compared to how concerned I am about someone on the Internet gaining access to my passwords somehow. Of course I look the doors to my house and don't leave my laptop just lying around :)
Although I think that for the general (ie not ultra-critical) U2F use-case, not having all the keys enrolled is acceptable, if you're able to log back in without them, say by using codes stored encrypted with the GPG keys of all the others.
The 4 in the vaults are only used for PGP.
I have a script that will PGP encrypt a file to all 10 of the Yubikeys. I keep track of all of the fingerprints and pubkeys in spreadsheet.
My $500 worth of Yubikeys has lasted me 5 years and counting, so we're at <$10/month TCO. That's to have 10 of them.
This is not an option for the vast majority of people. But While we are at it, if the government wants to confiscate your bank locker they totally can and have access to all your secrets. So then what do you suggest?
A bank SD box costs $50/year. Why is this not an option for a majority of people? If anything, it's more accessible to use a bank SD box than being a technical enough person to run code from a GitHub repo.
> But While we are at it, if the government wants to confiscate your bank locker they totally can and have access to all your secrets. So then what do you suggest?
The bank SD box isn't full proof (as any bank employee could take a peek), which is why you'd want to shard the secret into multiple SD boxes. I.e. if your secret is ABC, you could store three secrets of AC + AB + BC, wherein you need only 2/3 to recover the entire secret. This scheme is effectively the same as Shamir Secret Sharing, but way easier to recover.
If your threat level is that the government might confiscate your bank locker, then you're probably at the level that you'd want geo-distributed sharded secrets in privacy-centric countries like Switzerland.
Or often also just ask the service that you’re protecting a login for for your data directly.
But there are actual setups where storage can be encrypted with a Yubikey, and the Yubikey is protected by a PIN that's in your head, and other possible factors, so now we're in $5 wrench territory.
https://keytern.al (website painfully out of date)
I estimate the hundreds of thousands of cryptocurrency private keys we safeguard (in conjunction with the keys held in other organizations, via multisig) have at points in time protected somewhere on the order of single digit billions USD.
We're not a wallet provider, just a backup key storage service, so I couldn't get exact figures even if I wanted to: by design we don't have that information about our customers.
The PGP-encrypted keys are held completely offline (cold) in vaults, the set of Yubikeys (in other, different vaults) is used during signing ceremonies to temporarily decrypt them (only in ram, on offline computers without storage) to produce recovery signatures when our customers run out of other options. We're the last resort in a DR plan.
It requires careful coordination with another keyholder (a different organization) to produce valid transactions; neither ours nor theirs alone is sufficient. Transactions need two signatures: one from each. In that sense, neither key is "worth" anything by itself, but together they protect large sums.
Very few people have this threat level and the will power to go that far.