You're not wrong, but this is exactly the use case for a USB security stick. The key is in there, cannot be extracted in any way*, can only be "used" (not accessed or copied, just used for crypto operations) while the stick is plugged in, and without it it's impossible to proceed.

It kind of goes without saying that losing the key results in you getting locked out - if there was any other way there wouldn't really be much of a point to the complication of making yourself dependent on a stick.

As a backup, you either have some kind of spare keys in safe storage or reliable access to someone who can restore your access after having identified you.

* in some case you could generate the key beforehand on a computer, and then load it on a stick (unsure about yubikeys though). You should still revoke your key anyway once your stick is lost - as you should assume it could be found and used, sometimes needing only a touch operation rather than a PIN.

> It kind of goes without saying that losing the key results in you getting locked out - if there was any other way there wouldn't really be much of a point to the complication of making yourself dependent on a stick.

> As a backup, you either have some kind of spare keys in safe storage or reliable access to someone who can restore your access after having identified you.

I have two Yubikeys, but I don't consider the second one as "spare" that has to be locked away. I carry one USB-C/NFC key on my key chain. The other is a USB-A Yubikey nano, which is always at home in my desktop's monitor USB port so I can reach it very easily. By using both regularly, I'm more likely notice if one key gets broken or lost.

> * in some case you could generate the key beforehand on a computer, and then load it on a stick (unsure about yubikeys though). You should still revoke your key anyway once your stick is lost - as you should assume it could be found and used, sometimes needing only a touch operation rather than a PIN.

You can do that with yubikeys. You can copy the same secrets to a different key or store them somewhere safe. I considered doing this, but in the end all services that I use allowed to add two keys which seems like the better option. My reasoning was that if I have two identical keys A/B and I loose key A, I would have to immediately invalidate key B too - but before I can do that I would need to:

1. get a replacement key C 2. setup new secrets for key C and store them 3. then log into every service to add the key C and remove key A/B 4. reset key B to use the same secrets as key B

Up until point 3 (which my take a while until I get key C, unless I would always have a third key lying around) all accounts are vulnerable. On the other hand if I have two separate keys with different secrets, I can just remove the lost key from all services and deal with the replacement key later.

>I have two Yubikeys, but I don't consider the second one as "spare" that has to be locked away. I carry one USB-C/NFC key on my key chain. The other is a USB-A Yubikey nano, which is always at home in my desktop's monitor USB port so I can reach it very easily. By using both regularly, I'm more likely notice if one key gets broken or lost.

yeah, this is the way to do it. worrying about losing keys is a valid concern for webauthn where some poorly-configured services might only let you enrol a single key, but we've (mostly) got ssh figured out by now and everything lets you use multiple keys. so register and use multiple keys on a regular basis.

> cannot be extracted in any way

There was (is?) a vulnerability in Google Titan keys (and some Yubico products as well) that allowed cloning of keys (having a physical access is a pre-requisite).

https://news.ycombinator.com/item?id=25675556

If you lose a key you have to take action as if it were compromised, because there may always be key recovery attacks, but chances are the vast majority of attackers aren't going to build a machine learning, electromagnetic measurement recovery system.

Also the Yubikey NEO that was impacted by this is pretty old, released in 2012 I believe.

> 1. The impacted Yubico Yubikey Neo is an old product no more available for sale. All FIDO U2F Yubico Yubikeys currently available on their webstore are based on a newer secure element from Infineon, and are not impacted by our work to our knowledge.

I actually wish there was an in-between model that supported key extraction.

Let me store my key in a secure, offline, physical device... and extract to clone it when my yubikey is worryingly old.

My threat model does not include physical attacks, but storage of a key on-device or in backups? Or forgetting a password for an encrypted archive? yep.

Yubihsm can do that. Not sure about yubikey. It’s called export wrapped. Here wrapped means the export is encrypted by another key first. The only catch (feature) is that the key must be created with this capability on its initial creation, you can’t export a key that disallows exporting.

The robot arm part of this reminds me so much of StorageTek’s tape drive robots. Man those were so cool to watch wizzing around in their giant tubes grabbing and loading tape drives on demand.

The spare in safe storage has limited value: you have to take it out of the safe to enroll it. This is technically easy to solve (with public key cryptography), but I don’t think FIDO/CTAP/WebAuthn has any ability to do this.

Not sure I follow. Don't you just need to save the public key somewhere, and use that to enroll? Why would you need access to the yubikey itself to enroll?

I’m only deeply familiar with the U2F (legacy) protocol, and such devices don’t expose a key pair usable for this purpose. When you enroll, you need to communicate with the token.

But more generally, this is a protocol issue. You can’t enroll your Yubikey with your browser and then, later, have your browser enroll that key with a WebAuthn-using site. You have to put the key in your USB port at the time you enroll with a website. And you can’t do this if it’s in a safe.

That's a very good question and in my opinion the biggest flaw with almost all new 2FA/passwordless systems. The "best practice" is to get a second yubikey or store recovery codes on paper, but that requires keeping them close to you because you'll need to update your backup on every new signup.

That makes these systems entirely useless at protecting against house fires, signups while away from home, or simply services that are too lazy to support your backup style (looking at you, AWS).

I think what we need is one master key that can be backed up in a offsite location (e.g. safe deposit box, lawyer, parents, trusted friends), and then have all subsequent secrets generated from it, or encrypted with it and stored somewhere publicly accessible.

I think people start with trying to do the best practice too early. Just using one key as your primary authentication adds a lot of security as other authentication methods aren't as routinely exposed. That's enough to get started and makes it easier to think about backups when one is ready for multiple keys.

> Just using one key as your primary authentication adds a lot of security

Yeah, and look just how often people lose or wash their phones or their keys, or how easy it is to break off a Yubikey that is on a keychain (e.g. when a cat pulls on it). Then you are usually royally screwed.

Sounds like FUD to me. If you lose your primary method you have to remember the password to unlock your secondary software ssh key..

Possibly remembering a password is a huge crisis but I had that crisis before using tokens, i.e. returning to my work desktop after a vacation.

> If you lose your primary method you have to remember the password to unlock your secondary software ssh key..

The post I was replying to was talking about 2FA in general, not just for SSH keys. Many people take the advertisements of Facebook, Google, Twitter et al. to push for 2FA as pure gospel, but completely neglect "worst case recovery" scenarios - and then run into stone walls when it inevitably happens, because FB/GOOG/TWTR don't offer any sort of customer support (other than raising threads on HN, and even that is similar to winning the lottery) and Amazon AWS doesn't offer multiple 2FA keys at all.

The laws of statistics mean that even if something happens only for 0.001% of all users, at the scale of the big tech companies it still hits tens to hundreds of thousands of people, who have no recourse at all and are now completely and forever locked out of their online identity. Simply because they have not known about the failure modes.

We here, who debate on HN, know about the dangers and how to prevent them. But our parents? Our siblings? They do not, and companies push them to extremely irresponsible practices nevertheless. We can't go and claim on the one side (when fighting against surveillance, backdoors etc.) that our online identities and presences are extensions of our minds and should be protected, and at the same time make it so extremely easy for people to lose access to them!

AWS not offering multiple 2FA keys is one of my biggest annoyances, its a service that I feel much have 2FA due to its ability to run up extreme bills, but I also cant setup a backup key in case of loss or failure.

It is a big annoyance but I think most places (once they're beyond a few engineers in size) use federated auth that support multiple keys (Okta, Active Directory, GSuite) for AWS access.

You can also use TOTP and store the secret in a password manager then protect that with hardware keys.

At $JOB-1 we solved this by building a virtual TOTP service that grabbed the MFA secret for a particular AWS account from our internal secrets tool (which itself required MFA and supported multiple users) and used it to generate codes.

> something happens only for 0.001% of all users

Like a fisher taking their account and convincing support they are the real user? You can't really blame fido for the fact that consolidation made a dangerous situation. I'm very happy with my past choices to intentionally lock myself out as a failsafe over a 50/50 chance that it's me who gets an account back.

OK, how often? Seems like a relatively infrequent issue, although at the scale of cell phones it certainly happens "often".

But you aren't really screwed, you can recover your accounts. You still know your password, you likely have an associated email, you may have even written down your recovery codes.

You can't login without the second factor and only the password because that is literally the entire point of having a second factor.

You should not be able to reset a 2FA token purely by having access to the target's email (or SMS) account in a halfway decent system.

Your only hope will be the recovery codes but well, how many people actually read the fine print on these?

I'm saying that if you have the password and the email address, bypassing 2FA would not be unreasonable, and it's what most services end up doing (for better or worse). Recovery codes are the ideal, of course.

But yeah, this is also why every new Android/iOS device can act as a FIDO2 token - the more tokens people have, the easier it is to recover with a second token vs having to fall back to less safe methods.

>or their keys

How often do people actually permanently lose their keys (besides just misplacing them or leaving them somewhere and getting them back)?

I'd saying losing keys (house key, car keys) is fairly rare.

How often have you had a flash drive that stopped working for some reason?

Physically losing the keys isn't the only way to lose them.

>I think what we need is one master key that can be backed up in a offsite location (e.g. safe deposit box, lawyer, parents, trusted friends), and then have all subsequent secrets generated from it, or encrypted with it and stored somewhere publicly accessible.

This is a very good point. Essentially what you are describing here is a certificate authority.

The Yubikey, in this scenario, just acting as an 'offline CA'

It's a very good idea, but requires software being built to accept an authentication hierarchy.

A lot simpler than a certificate authority, actually. There's no need for hierarchy, x509, or anything of the sort.

Take SQRL[1] for example. It's a login system where you scan a QR code with your phone, then your phone derives a private key based on the domain and a master key, and use that to sign a challenge. Every other device (including offline backups) will generate the same private key, and hence give access to the same account.

[1] https://www.grc.com/sqrl/sqrl.htm

For signups away from home, use the key you have then add the second when you get home.

I sign up for a lot of services when I'm on vacation (local taxi, event and tour guides that now require apps, SIM card contracts, etc). Losing/breaking small electronics is a big risk when traveling, so I wouldn't use Yubikeys for those even if they are supported.

As someone who uses Yubikey for about 5 years for SSH, GPG and O2F, an extra key is indeed the solution I use.

Effectively it means all integrations must support multiple keys, and you’ll have to register both. Of course, this doesn’t work everywhere, such as AWS. In those cases, I typically use my “main” key.

I’d argue that the key breaking due to wear or being lost is less of a risk than human error: just last week I had to enter the admin GPG code for the first time in years, and I forgot it initially, which caused the device to lock itself, and apparently the recovery code didn’t work. Caused me a few hours of stress to get it resolved.

So yeah it requires some discipline. What’s important is that you need to identity the services you absolutely cannot lose access to: in my case it’s my email and password manager. For those two, I properly manage backup codes, regularly test both yubikeys, etc. The rest can all be recovered through email, if it needs to be.

You pull your GPG key from offline backups, reset the applet and load it again.

The same Gpg key can be used for SSH too.

You can generate keys inside Yubikey, but you also have the option of bring your own key, which surely you keep safe offline.

> Of course, this doesn’t work everywhere, such as AWS

I’ve worked around that by creating one IAM user per Yubikey.

I have a question - do you disable regular OTP 2FA on services you use the Yubikey? I have one too and religiously added it to all kinds of things, but each service allowed me to just skip the yubikey when a regular OTP code was entered, effectively making me not use the yubikey

If you have only one Yubikey, and use it as the only factor of authentication to a website, you'll need to ensure you store the 2FA recovery codes safely. Whereas, if you have both Yubikey and TOTP as factors of authentication, if you lose the Yubikey, you'll still be able to login.

I view that as "Yubikey more convenient than TOTP". You can either use TOTP, or the Yubikey, and it's easier to tap a button than to enter a code.

WebAuthn is more convenient but also more secure. You don't have to be as vigilant when checking what URL your browser is pointing at.

Not the GP, but I also use YK as a primary auth mechanism and TOTO as fallback.

Since I only use TOTP as fallback, I am much more vigilant if I suddenly get a TOTP prompt. I should never get one, only in circumstances where I explicitly want one. Every other instance is a big red flag. Is that perfect? No. Is it better than TOTP: yes.

>just last week I had to enter the admin GPG code for the first time in years, and I forgot it initially

Now this is scary.

I'm going to reveal some of my opsec but my password manager (pass(1)) does have yubikeys registered but it also accepts my GPG key. So even if I lose my yubikeys I can still unlock all the passwords, otp codes and everything I have in there.

I just can't feel comfortable with any other solution than my head being the final master key.

I use pass also but only with GPG and I feel a bit uncomfortable that I don't know anything about GPG, I don't remember if I set a password there or how to move it to another computer for backup or sync of the stored data in pass.

Yeah gpg is a big hurdle. My suggestion is to learn about subkeys. Create subkeys for everything you want to do.

That way you have one main key that can revoke subkeys, subkeys do everything like access to files, emails, passwords.

I backup everything directly to GitHub. I first encrypt/seal my passwords/files using a Yubikey+PIN then git push them.

Here's my take on the automation: https://github.com/mihaigalos/pass

Which password manager do you use that supports Yubikey?

Bitwarden's paid plan supports yubikey.

As does Vaultwarden - the self-hosted unofficial version of Bitwarden

I think the official recommendation is to store a second yubikey in a safe location.

Personally I just generated my key offline (on a tails livecd) and backed it up to two different LUKS-encrypted USB sticks. One of those is stored at my place and another one at a trusted person, in case my flat burns down or so. The yubikey itself only stores subkeys, my master key stays on said USB sticks.

Been using this setup for about 5 years now and it's been working well for me so far. Once a year, I extend my gpg keys expiration time by using on of the USB sticks.

No need for LUKS usb. Gpg stores private keys encrypted with a password.

At that point, you can store the encrypted key anywhere.

Ah yes good point for the gpg key itself, but I store a few other important secrets there as well ;)

Does this also work for the WebAuthn / U2F / TOTP use cases, or just the PGP/PIV/SSH ones?

No. There is no way to push a value for the symmetric key that probably makes the FIDO (thus U2F / WebAuthn) feature work. You can tell the Yubikey to pick a random new one, effectively wiping your key (and rendering any credentials previously minted with it now invalid) but you can't write one over USB and this was I believe intentional.

Thanks. I will wait until it’s actually possible to create back up webauthn keys (rather than enlisting two keys with every service).

There is actually at least one fido2 device that supports backing up (mostly), based on this spec from Dicekeys https://github.com/dicekeys/seeding-webauthn

Solokeys (https://solokeys.com/ - v1, don't think the newer v2 does) have a special firmware version that implements this and allows you to use a custom seed - and as such restore a key from it. It only works on non-resident credentials (most commonly used, as the number of RKs is usually very limited) though. The firmware is here https://github.com/conorpp/solo-dicekeys/releases/tag/5.0.0 But it's also shipped in the keys dicekeys sells and I think only their app implements the client side of seeding anyway: https://www.crowdsupply.com/dicekeys/dicekeys

Thinking carefully about loss scenarios is really important, so you're thinking about the right things. I used to have my SSH key on a Yubikey for awhile and now I have it in my MacBook's secure enclave guarded by TouchID. In both of these cases I'm not terribly worried about loss because it's almost always the case that loss of SSH access is pretty easy to recover from. In most cases other people on my team also have SSH access and can swap out my key if I lose the Yubikey. In a number of other cases the cloud server doesn't have any/much in the way of irretrievable data. It's just running various software that is usually version controlled with git. So even if no other team member had access it would be pretty easy to spin up another machine to replace the one that I can't log in to, change the domain name to point to the new machine, and terminate the old one.

You're not overthinking it at all. I have two YubiKeys for that reason. I also have a fire safe with some important docs in it (hopefully the yubikey won't melt!). Plus, I'm older, and I'm getting forgetful, and I worry I'll forget my long lastpass master password some day, let alone all my SSH keys. There are real assets tied to my passwords. Fortunately at my age I have a relationship with my estate lawyer, and financial advisor, who has power of attorney so most of that is safe, but I don't think anyone has really figured out how to handle long-term digital assets. In fact, I'm actually working on a side project to do this.

I don't have two keys. I do keep a fallback method like restore keys written on a safe place.

I did find out however that my old Ledger X can do U2F and GPG so I'm trying to learn how to use it. This Ledger was my first first hardware wallet but I got a coldcard which in my opinion is a better bitcoin wallet. I had no idea what to do with the ledger - second hand market for these things are a big nope. I was pleasantly surprised when I found out there are apps that allow the Ledger to perform some of the Yubikey functions.

> but don't really know where I would feel comfortable storing the extra key

So this doesn't really matter, because with enough incorrect PIN attempts the YubiKey will wipe the credentials. Store it somewhere it won't get destroyed, but don't worry too much about theft.

I thought about this when getting my two YubiKeys as well. I have one on my keychain. Sure I can still lose my keys, but I've had that happen probably once in my life so far. The other one is stored in a relatively safe space in my house. It isn't particularly well hidden or anything, just in a spot out of sight that I can easily remember. After a few months of using them it hasn't been as much of a hassle as I originally thought it might be.

I think that might be only half of the solution. Whenever I have to keep two things in sync—like, in this case, two security keys—, it's always been trouble waiting to happen.

What I'd love to see would be some kind of "trust relationship" between two security keys – ie, if I had set up an account with key 1, but tried to access it with (transitively-trusted) key 2, I would be granted access.

I personally store a printed copy of an emergency-only SSH key (ed25519) in a safe, also formatted as a QR code to quickly import it if something goes wrong. The key is short enough to fit within a QR code length limit, and I can quickly scan it to my computer using my 2D barcode scanner.

I just import my `authorized_keys` that I keep up-to-date on my new server when I do the initial setup.

I was thinking the same initially. But I've been using my Yubikey for 6 or 7 years now, haven't lost it, haven't lost the recovery key which you create during initial setup, and it survived three times being machine washed. I don't know your full situation, but I'd say people are generally much better at not losing things than they think they are.

Encrypt the private key with a strong one time password which you print off (multiple copies) and put in safe places.

This is perhaps not ideal perfect security, but ultimately security is a always a tradeoff with usability and losing a physical item probably has greater chances than someone deliberately trying to get your private key.

You can generate keys off-yubikey and store them in a safe encrypted backup somewhere offline/online/wherever. Then just import those keys into yubikey and use that.

Ideally though you would rotate keys if you lost your yubikey because you never know if the password was compromised or not.

After buiyng a Yubikey and using it for like one year, I now use 1Password to manage all my MFA.

It can work like Google Authenticator (using OTP), except it's not tied to a single device.

Not as safe as Yubikey, but likely a good compromise between security and user stupidity protection.

Also:

- 1Pw blocks itself after a few min without use.

- Installing 1Pw for the first time in a device is a bit more bureaucratic than a simple login.

I really think any MFA needs something to protect users from forgetting stuff to be successful. Even if it's something stupid like going physically to a store. I can't stand the idea that by loosing my two keys I will loose access to all my things and there's no one who can help me.

1Password is super convenient for MFA, but it's really FAKE MFA. You password and the OTP secret are both stored together, in the same vault, guarded by the same password.

If one is leaked or accessed, so is the other.

It only really provide protection against the most basic / passive MITM attacks.

Most providers also let you create recovery codes. Or signup for TOTP which gives you a QR code.

Print those out and store them somewhere. Then if you loose your yubikey you recover access with those.

If you're too lazy to print them, the just store them in an encrypted tarball, using a very long password (and then rarely open it).

Having the extra key is also fine, but it means you need to have the key around whenever you signup for a new service.

In an ideal world, I would encrypt recovery codes with a public-key and have the private key for decoding them buried in the back yard.

My Precursor† arrived last week, I'm optimistic about the direction the project is going in. Once the ecosystem is fleshed out, we should be able to store secrets with high reliability and deniability, combine this with something like tarsnap and it should be possible to recover everything off a piece of paper, from anywhere, with a fresh device.

†: https://www.bunniestudios.com/blog/?p=5921

If your whole life is on your phone like me, just attach a yubi to your actual keychain (which is stuck to your phone) and then you'll always be thinking about where your phone/wallet/keys/security are all the time.

Then put the second key on your desk. My yubi happens to be annoying to fiddle with since it's on my keychain, so I use the desk one for signing most of the time.

If there's a house fire, you'll have your phone on you. If you lose your phone, you'll have a key at home.

You're missing the scenario where the police take your phone and your electronics (and the yubi on your desk) and have access to all your accounts because of the yubi attached to it, and you're left locked out of everything.

I am often quite baffled by people using only the device.

The whole point of all this is "something you have, something you know".

Yet lots just have passwordless keys for ssh with their yubikey. Completely unsecure, unsafe in examples you cite, and more.

When using ssh keys for login, you should enforce remote/server password requirements and an ssh key. This is trivial to do in sshd_config, and important.

Never trust end users to have passwords on their ssh keys. Always enforce it server side.

I'm a long-time Yubikey user (since they arrived) and I keep my Yubikey on my keychain, with my house keys.

I've a USB dongle at my office workstation (not a laptop, good ol' desktop) and I use Yubikey to store boot decrypt password. I do have a backup.

The anecdote is this: I have to take my keys out of my pocket and then insert Yubikey into the dongle. Naturally - I forgot to take the Yubikey and the keys back, cycled back home (6km away), realized I don't have the keys to my house, had to cycle back, couldn't get into the building, had to call my coworker to come back to let me in.

And I'm glad it happened. For the past 4 years (since it happened), I've muscle-memory when it comes to handling my physical keys and how I use the Yubikey.

Keychain stuck to your phone? I don’t think I’ve ever seen anyone with a setup like that. Sounds incredibly annoying.

Well I've only got one key on the chain, though my wife has a couple of them. Nothing too cumbersome, plus I have a strap that's useful for pulling the phone out of my pocket.

Wait, I read that quicky in your prior post. I thought you meant a software keychain.

If you ask me, drilling a hole in your phone will invalidate the warranty...

As others pointed out, you just add another factor (TOTP) or print backup codes.

Or just have another way to sign in. Generate random password for root user, store it in your password manager, disable root login via SSH and... whenever you find your user locked out, log via root via console. In a corporate environment, you could audit and alert whenever root logs in as it should be only "recovery" user.

Keeping an extra key stored away works well enough.

IF my primary key gets lots, I'd hope the one backup one won't suddenly fail that same day -- if it does, then there's a problem.

The annoying bit is having to add all 2FA tokens to the backup one -- which is tricky if you want to store if off-site, since you need to bring it in every once in a while to add all the new 2FA secrets to it.

Am I living too dangerously? I keep two U2F keys enrolled, one as a backup in a safe place, the other on my keyring. And for sites that still use passwords, in-browser password manager works well for me.

What kind of key-breaking do you think can still screw me over?

That’s what makes these keys so secure. Most people I know keep one on their person (keychain), one in a locations they have easy access to (hidden at home), and one off-site. You still have a password as the first line of defense so don’t overthink it.

Any system with a backdoor can be exploited. Keep a large number of spare keys that are revokable instead.

Given my "threat model", I don't need a lot of security, so that's one on my person, two other places that are in tamper evident containers.

My thinking is the same. That's why I, in addition to the second USB stick, also have a plain-text copy stored on paper in a safe. EC keys are even short enough that you don't have to involve a printer in the process.

I haven't kept track of these, but are there no solutions to have a master key that one can create any number of keys from? And where that would not require one to update all hundred services using it.

I think this can do that

https://github.com/Logicwax/gpg-hd

You obviously keep backups (either in form of another YubiKey or backup codes). That's just common sense, you don't only have a single house key either right?

In the physical world I can call a locksmith. For work related MFA I can call my manager / IT. For personal accounts I do stress a bit about locking myself out - obviously have backup codes etc, but unfortunately I'm not sure that I could regain access to say GitHub or Google accounts if my backups failed (hopefully never need to find out)

I keep my backup key in a drawer with a bunch of papers and records and shit. It's also where I keep my 2FA backup codes, and a few other decryption keys.

Out of interest if you lost both, what would you lose access to permanently?

My Yubikeys (main and spare) are attached to keychains with AirTags....