I'm probably just over thinking this and overly paranoid.
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.
> 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.
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.
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).
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.
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.
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 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.
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.
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.
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!
You can also use TOTP and store the secret in a password manager then protect that with hardware keys.
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.
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 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?
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.
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.
Physically losing the keys isn't the only way to lose them.
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.
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.
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.
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.
I’ve worked around that by creating one IAM user per Yubikey.
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.
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.
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.
That way you have one main key that can revoke subkeys, subkeys do everything like access to files, emails, passwords.
Here's my take on the automation: https://github.com/mihaigalos/pass
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.
At that point, you can store the encrypted key anywhere.
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
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.
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.
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 just import my `authorized_keys` that I keep up-to-date on my new server when I do the initial setup.
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.
Ideally though you would rotate keys if you lost your yubikey because you never know if the password was compromised or not.
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.
If one is leaked or accessed, so is the other.
It only really provide protection against the most basic / passive MITM attacks.
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.
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.
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'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.
If you ask me, drilling a hole in your phone will invalidate the warranty...
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.
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.
What kind of key-breaking do you think can still screw me over?
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.