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