[XorNot]

I feel like leaving the "backing up" section of this till last is burying an important part of realistic threat analysis here: i.e. the risk of losing access to data from losing, accidentally destroying, or a malfunction of your Yubikey is substantially higher then the risk of compromise.

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.

[tw04]

>or a malfunction of your Yubikey

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.

[nixpulvis]

On the flipside, I’ve had a Yubikey 4C for around 4 or 5 years on my keychain in my pocket, and it’s holding up OK.

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.

[graton]

I have Yubikey nano in my laptop, desktop, and Linux PC. All of them are still going strong. I have four Yubikeys on my keychain, two of which I bought in 2014, and they also are still working without issues. None of my keys have ever failed.

[downrightmike]

Think about it this way: forcing electrons through a circuit is abuse. Since they bumble around like flowing honey looking for the easiest way out.

[aborsy]

Yubikeys are well constructed. I don’t think they die frequently before several years.

[tomxor]

I can't stress this enough, risk of losing (or breaking) your security keys is the number 1 threat when a service (correctly) offers no way to circumvent it's absence.

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.

[matthewtse]

It's for this reason that I eventually decided upon pencil+paper secrets in a bank safety deposit box, which can be backed up or even split up in a 2/3 fashion for things super critical.

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.

[victor106]

> It's for this reason that I eventually decided upon pencil+paper secrets in a bank safety deposit box

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?

[matthewtse]

> This is not an option for the vast majority of people

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.

[victor106]

This is interesting, never heard of Bank SD box and the way you describe distributing the secret is novel. Do you have any links to a practical implementation?

[lxgr]

The government can totally take and use your Yubikey as well.

Or often also just ask the service that you’re protecting a login for for your data directly.

[NoZebra120vClip]

If you're using a service.

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.

[tomxor]

Yeah the only thing that can beat the $5 wrench is plausibly deniable encryption + training to pass a polygraph.

Very few people have this threat level and the will power to go that far.

[Guvante]

And all YubiKeys die it is just a question of when.

[brantonb]

> This is the same for encryption: the number 1 threat is lost encryption keys

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.

[matheusmoreira]

Agreed. Turns out the best backup medium is paper: print out the secret bits and store them in a safe. The paperkey tool can do this and QR codes can make it really convenient. I even added binary decoding interfaces to zbar to support this exact use case.

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

Not every key needs to be backed up. Signing keys are ephemeral, losing one is inconsequential. Losing an encryption key means it'll be impossible to decrypt data later so backups could be interesting. The master key should be kept permanently offline in a physical safe.

[dier]

Like the other comments, the risk of losing data/access/etc is not enough.

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 suppose this is why it's an Opinionated guide as my opinions on how the actual target of a "remote adversary" should go about balancing security with risk.

[aidenn0]

Yeah, if you're paranoid about the key being stolen when generated, just unplug the network, boot a live DVD image, store it directly to a USB stick, and then unplug the USB stick before rebooting.

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.

[chiefalchemist]

The simple solution is to buy two, or more. Mind you, Yubi could be more upfront about the risk and the solution. But it's pretty obvious pretty quick that if your access depends on a single physical key that one key isn't enough.

[carbocation]

I don't enable Yubikeys unless I can assign at least two to my account.

[chiefalchemist]

It's that simple. Yubi should just be a bit more transparent about the need for two or more.

[lathiat]

I have this same discussion about people using Vault and having secret unseal 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".