Issue the user two smartcards, one for daily use, one that can be used to create a new daily use smartcard. Tell the user to keep the backup smartcard in a safe place.
Yes, someone will inevitably lose both. You just need to ensure that that is a rare event, and that there are alternative systems in place (i.e. that losing access to one system does not prevent people from living their lives).
This has become a pretty big problem for me. I keep the backup key offsite, and retrieve it every few months to enroll as a backup device with new services. I try to keep a list of services I need to enroll it in, but I've definitely forgotten to do so at times.
Ideally there would be a way to enroll the second device without possessing it, but I'm not sure that's technically possible.
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.
I think that worry makes sense. It is a good idea to keep a backup. For example, you could get two YubiKeys, use one as your primary, and put the other in a safe place as your backup.
It is a little bit of a hassle. But changing 200 passwords because LastPass was breached is also a hassle.
To make a backup, you get 2 different keys and set them both up. The second one you keep somewhere safe, for example in a safety deposit box at a bank.
>- The ideal backup for this is to have a separate key, both authorized.
This in particular is important. Security is only as strong as your weakest link, so any backup methods (e.g. "forgot password" flows) might as well be your primary method, if you actually care to strongly secure things.
Adding another (or more) key gets you same-security redundancy if one fails or is lost. Nothing else will achieve this.
Degrading to "forgot password" may be entirely fine for [person's] use of a security key, but you must be explicit about that decision, or it's mostly security snake-oil.
The basic idea is to have two U2F devices with with the same device_secret but one of the devices (the backup) is pre-programmed to add a large offset to the so called counter value. Upon login the service must check the counter value and ensure that the received value is greater than the one it's seen previously. If you happen to lose the first key, you can use the second key to log into all of the affected online services and upon doing so, the service would accept the new larger counter value and thereby invalidate the lost key.
> 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 didn't explain it really well. I wasn't too worried about it being stolen. I was worried about having a single device, so losing it means losing all the identity info. I guess it's no different than now where I enroll 2 keys everywhere.
the idea is to generate the key in the device, so it never leave the device, therefore you cannot store it somewhere else like another device.
So, the ideia is for you to have two devices, each with its own key, the first device you use daily and the second you use store in a safe location.
if your first device in daily use stop working or is lost you use the second device you have stored to login to your systems to remove the keys from the lost device and add the keys for a new device that replace it and then store the second device back in a safe location.
> The other key feature usually found in HSMs but not smart cards is backup/cloning without exporting the key (in PKCS#11 terms). This means that the key can be moved between HSMs with all the protections in place. I've yet to see a smart card that does this.
How does this work? Can an attacker buy an identical HSM, back up the key, and restore it onto the new HSM?
No, that's like having only one key to your house.
If you have two passkeys from different providers, they serve as backups for each other. And there are other alternatives, like a printout of recovery codes.
The trouble with this is that you need the second key present each time you need to enroll it to an account, meaning you can’t stash it in a safe deposit box as a backup. And you have to remember to add it to each and every account or it’s not really functional as a backup.
Yes, two different keys are more secure, but they have some pretty severe usability problems.
The usual solution for this is to have multiple keys. It's logically equivalent to having a backup key, but it's more secure because if you lose a key, you can use another key to disable the lost key.
You can add multiple keys, so you could have a primary one that's with you and another one that's stored somewhere safe. You can also configure OTP and/or SMS-based 2FA and backup/recovery codes as a fallback mechanism.
The problem with that is that it requires to have all these security keys available in order to enrol them, which is not possible if you want to store one of them in a different secure location. If you have two keys in your pocket, that's not much of a backup; having two identical keys means that you can enrol the one in your pocket and if it gets lost, the copy from your safe works.
I deal with this by always adding a second "cold" key when services allow multiple keys, and keeping this cold key somewhere secure as a backup spare. So if I do, say, lose my primary key, I can at least pull out the spare key to reset and de-associate the primary.
Yes, someone will inevitably lose both. You just need to ensure that that is a rare event, and that there are alternative systems in place (i.e. that losing access to one system does not prevent people from living their lives).
reply