Hacker News Reader

Comment by ryukafalz | Hacker News Reader

Unfortunately for the user experience, those tokens typically can’t be cloned even upon initial setup. The practical result of this is that if you intend to keep a second token as a backup, you need to remember to register the backup token individually for each service you use your primary one for. This is unlikely if you keep the backup at home, and it’s downright impractical if you kept it in e.g. a safe deposit box.

I love FIDO tokens, but I’m not confident in my ability to keep myself from getting locked out of a service I use infrequently, and I’m a fairly technical user.

View on HN

> Unfortunately for the user experience, those tokens typically can’t be cloned even upon initial setup. The practical result of this is that if you intend to keep a second token as a backup, you need to remember to register the backup token individually for each service you use your primary one for. This is unlikely if you keep the backup at home, and it’s downright impractical if you kept it in e.g. a safe deposit box.

This right here is what drives me crazy about most 2fa implementations (and now apparently webauthn). I currently store 1 backup token offsite, and carry one with me. The problem is - I have no good way to access the backup device (so I can add it to my account) without having both in my possession, which destroys its abilities as a backup token.

I would love to be able to somehow have 2 fido keys use the same key, but I'm not sure how that's possible without exposing the private key externally, destroying some of the device's security properties.

You could have a single soft-U2F vault that contains all your accounts, and secure that vault with your hardware tokens. Using something similar to LUKS (http://clemens.endorphin.org/TKS1-draft.pdf), you could allow multiple tokens to decrypt the vault without exposing the master key. The downside is that there’s no way to revoke access to the vault if a copy leaves your possession.

There are tokens that support this. OnlyKey has a secure backup feature where you can have an encrypted backup file. If you lose your physical key you would just load the backup file onto a new key and all of your accounts are ready.

https://onlykey.io/

https://docs.crp.to/usersguide.html#secure-encrypted-backup-...

Allowing backups is as you mentioned a tradeoff of security vs usability. The greatest risk to your accounts is not always account compromise, it can be losing access to your own accounts. With OnlyKey you can choose to enable this feature or not. Backup requires user physical presence and restore requires the backup file and correct key/passphrase.

There are other recovery modes that don't require a second token.

One common example is a sheet of recovery codes you receive at the enrolling stage that you are prompted to print and store somewhere safely.

I've got a system where I mail these one time codes (via snail mail) to a family member as a failsafe. I only use this for 2fa, but that ensures that if I lose my key while say out of the country, I can call my family member and they can read me some codes over the phone.

It's a bit archaic in a way, but works wonderfully as an accessable and relatively secure backup strategy.

Reply on news.ycombinator.com