Hacker News new | ask | show | jobs
by gruturo 1485 days ago
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.

4 comments

> 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.