6 ms·

Genuine question: if you can't clone your 2FA, how do you make spares like a house key ? If there is way to get a spare, what's the way to deal with key loss or

Genuine question: if you can't clone your 2FA, how do you make spares like a house key ? If there is way to get a spare, what's the way to deal with key loss or shared access ?

jon-wood 8y ago
You don’t make a copy, you add an extra key. (Almost?) all services that support 2FA keys allow you to add multiple keys.
dspillett 8y ago
Essentially you have a to configure the account/device you are authenticating with to accept multiple keys permanently (so you can have spares) or temporarily (replacing a key by registering a new one then revoking the old). In the case of key loss on a properly secure service registering a new key could be problematical if you don't have any other key that is still appropriately registered - you might be permanently locked out unless there is an admin function who has a key registered so can do it for you. Look at multi-key options for encrypted filesystem for one way that this can work. Often the filesystem or block device has a symmetric key that is in turn encrypted by each of the keys that you wish to be able to open it. It is the same symetric key every time, though you can't unlock my copy of it with your key nor can I unlock your's. Once unlocked we could both add a third user by encrypting the base key with their public key (PKI is not required, but is not uncommon).
- sametmax 8y ago
  Ok, so you if you want 9 keys (3 persons in your family has access, have one local spare, and one off site), and 4 services, you need to do 36 registrations of keys ? Is there a standard to automate that ?
  - dspillett 8y ago
    You don't need one key per service, so that is as little as 5 keys (3 for active users plus the on-site and off-site spares). You may choose to have more than one key per person, to reduce the amount of re-registering needed if one key is lost, though remember that this is the second factor so you also already have passwords that vary by service (and if you give people multiple keys they will most likely carry them together to lose them all at the same time rather than individually anyway).
OJFord 8y ago
Unfortunately the analogy fails slightly, because the answer is that you allow another key to <do whatever> - each key can independently unlock the door. Like having several doors on your house, (though not a 'back door'..!) each with a different lock/key. _Not_ like having several locks on your one door, or multiple copies of the key for one lock.
wahern 8y ago
Other than registering multiple keys with a service (as others have explained), you can generate the private key off-device, import the key onto your device(s), then optionally delete the off-device key and/or archive it to external storage (e.g. disc stored in a safety deposit box at your bank).
- sametmax 8y ago
  So you can make duplicates as long as you generate the key offsite first ? Does it work with any hardare ?
  - bacon_waffle 8y ago
    At a basic level, the key is just a number, so there's no fundamental reason why it can't be duplicated. However, other responses seem to be leaving out a discussion of why one would want to make identical keys in the first place. If you had identical keys, losing one would mean you'd need to revoke permissions of all copies. If the keys are instead unique, then only the lost key needs to be revoked. Copying keys would also imply that the secret information needs to pass between devices, which adds some combination of risk and complexity. If the key doesn't need to support copying, then the secret information could be generated inside, and never leave, the key. It seems better if the permissions granted to unique keys are easy to replicate, rather than the keys themselves.
    - wahern 8y ago
      I agree that multiple unique keys are preferable. But for traditional PKI schemes there's always at least one key (your personal master PGP key, your company SSH/X.509 CA) you want copies of, yet it's precisely the kind of key you absolutely want to keep off the network or within a secure hardware token; more so than authentication keys. There are tokens that permit exporting (aka wrapping) a key for off-device storage or for transferring. If for transferring presumably you specify at key generation time a list of public keys to export to. But I've never used these tokens as the software was just too complex to bother with, proprietary, and poorly supported in the open source ecosystem. In the PGP world the typical advice (for better or worse) I've heard is to archive your master key on a disc and rotate your subkeys occasionally, necessitating brief exposure of your master key. Theoretically you would sign the subkeys from an old, non-networked computer.

Genuine question: if you can't clone your 2FA, how do you make spares like a house key ? If there is way to get a spare, what's the way to deal with key loss or shared access ?

jon-wood 8y ago

You don’t make a copy, you add an extra key. (Almost?) all services that support 2FA keys allow you to add multiple keys.

dspillett 8y ago

Essentially you have a to configure the account/device you are authenticating with to accept multiple keys permanently (so you can have spares) or temporarily (replacing a key by registering a new one then revoking the old). In the case of key loss on a properly secure service registering a new key could be problematical if you don't have any other key that is still appropriately registered - you might be permanently locked out unless there is an admin function who has a key registered so can do it for you. Look at multi-key options for encrypted filesystem for one way that this can work. Often the filesystem or block device has a symmetric key that is in turn encrypted by each of the keys that you wish to be able to open it. It is the same symetric key every time, though you can't unlock my copy of it with your key nor can I unlock your's. Once unlocked we could both add a third user by encrypting the base key with their public key (PKI is not required, but is not uncommon).

sametmax 8y ago
Ok, so you if you want 9 keys (3 persons in your family has access, have one local spare, and one off site), and 4 services, you need to do 36 registrations of keys ? Is there a standard to automate that ?
- dspillett 8y ago
  You don't need one key per service, so that is as little as 5 keys (3 for active users plus the on-site and off-site spares). You may choose to have more than one key per person, to reduce the amount of re-registering needed if one key is lost, though remember that this is the second factor so you also already have passwords that vary by service (and if you give people multiple keys they will most likely carry them together to lose them all at the same time rather than individually anyway).

OJFord 8y ago

Unfortunately the analogy fails slightly, because the answer is that you allow another key to <do whatever> - each key can independently unlock the door. Like having several doors on your house, (though not a 'back door'..!) each with a different lock/key. _Not_ like having several locks on your one door, or multiple copies of the key for one lock.

wahern 8y ago

Other than registering multiple keys with a service (as others have explained), you can generate the private key off-device, import the key onto your device(s), then optionally delete the off-device key and/or archive it to external storage (e.g. disc stored in a safety deposit box at your bank).

sametmax 8y ago
So you can make duplicates as long as you generate the key offsite first ? Does it work with any hardare ?
- bacon_waffle 8y ago
  At a basic level, the key is just a number, so there's no fundamental reason why it can't be duplicated. However, other responses seem to be leaving out a discussion of why one would want to make identical keys in the first place. If you had identical keys, losing one would mean you'd need to revoke permissions of all copies. If the keys are instead unique, then only the lost key needs to be revoked. Copying keys would also imply that the secret information needs to pass between devices, which adds some combination of risk and complexity. If the key doesn't need to support copying, then the secret information could be generated inside, and never leave, the key. It seems better if the permissions granted to unique keys are easy to replicate, rather than the keys themselves.
  - wahern 8y ago
    I agree that multiple unique keys are preferable. But for traditional PKI schemes there's always at least one key (your personal master PGP key, your company SSH/X.509 CA) you want copies of, yet it's precisely the kind of key you absolutely want to keep off the network or within a secure hardware token; more so than authentication keys. There are tokens that permit exporting (aka wrapping) a key for off-device storage or for transferring. If for transferring presumably you specify at key generation time a list of public keys to export to. But I've never used these tokens as the software was just too complex to bother with, proprietary, and poorly supported in the open source ecosystem. In the PGP world the typical advice (for better or worse) I've heard is to archive your master key on a disc and rotate your subkeys occasionally, necessitating brief exposure of your master key. Theoretically you would sign the subkeys from an old, non-networked computer.