7

A lot of services offer authentication with FIDO2, such as Twitter, but only allow the user to set one "security key". This is problematic in case the key is lost or breaks. The ideal solution would be to allow a user to set up multiple keys, similar to how Google does, but that's not something the user can influence.

As such, my solution would be to set up two or more keys in an identical fashion, so that either of the keys can be used when authenticating. This would allow the user to keep one key in a "useful" location (e.g. on their person), and one key in a "safe" backup location, such as a safe at home.

Is it possible to set up two YubiKeys to have the same secrets, so they can be used interchangably?

  • U2F keys don't seem to be importable. Yubikey 5 can import RSA-2048 keys using gpg and then use them for ssh: https://developers.yubico.com/PGP/Importing_keys.html – Z.T. Feb 08 '21 at 00:16

3 Answers3

4

FIDO2/WebAuthn relies on a public-key cryptography. The private key is stored on your security token. By default, you can't clone the private key, see https://www.w3.org/TR/webauthn-1/#credential-loss-key-mobility:

In general, it is expected that a credential private key never leaves the authenticator that created it. Losing an authenticator therefore, in general, means losing all credentials bound to the lost authenticator, which could lock the user out of an account if the user has only one credential registered with the Relying Party. Instead of backing up or sharing private keys, the Web Authentication API allows registering multiple credentials for the same user.

So the service provider (aka Relying Party Server) must allow registering multiple security tokens for backup purposes.

Yubi
  • 41
  • 1
  • 1
    That's kind of useless, since the server obviously doesn't. "Should" would be better than "must". –  Feb 03 '21 at 16:29
  • 1
    Well, I think the intended meaning of "for backup purposes" in that last sentence is probably "if backup functionality is needed", in which case the "must" makes sense. – Royce Williams Feb 04 '21 at 03:29
  • @RoyceWilliams This is all fine and dandy, but does absolutely nothing to change the fact that some services I use simply do not allow registering multiple security keys. –  Feb 04 '21 at 10:44
  • @MechMK1 100% no dispute there - single-key services drive me crazy. I was just responding to your wording feedback, and explaining how the wording might mean something different from what you were suggesting. – Royce Williams Feb 04 '21 at 17:53
  • 1
    So... excuse my ignorance, does having multiple security keys, say for a website that supports it, mean if I lost my keychain FIDO dongle, I could get my other one out of my safe, and use it? – Mark Stewart Feb 07 '21 at 23:56
  • I'm sure these keys are designed such that no specialized hardware can extract the private key from them in order to maximize security. Forcing two keys to use the same private key would likely require generating a new private key on a computer and writing them to the key. I'm not sure if and how that's doable. – vikarjramun Feb 09 '21 at 16:28
0

This is not possible, there is even protection against it. See section 2.6 of the "FIDO U2F Implementation Considerations" here.
If you try to clone a key, the website should lock you out, because your Token Counter did behave unexpectedly.

M1lk4fr3553r
  • 1
  • 1
0

Well this is in fact a feature. Strong authentication requires that you own an unique object, and know a secret. I you can duplicate the container of the secret key, it is no longer unique, and it might be used without the owner noticing it. Furthermore, being able to extract the secret key from a secure device like a smartcard in a rather short time is a serious flaw that could lead to the card to be blacklisted.

That being said, I am not a specialist for YubiKeys, and I know more about X509 certificates on smartcards. In that latter case, you have 2 ways to setup the private-public key pair:

  • the normal way which should be used for authentication or secure signing is to generate the key pair on the card itself. Once this is done, you can only export the public key, the private one is definitively locked inside the card
  • the external way which is should only be used for encryption. You generate a compatible key pair (algo and size suitable for the card) outside on a computer, and import both the public and private keys on the card. The card will no longer allow to export the private key, but that key can be stored (in a secure place) to be able to later decode a message if the card is lost or destroyed.

I assume that some keys could support that kind of import of the key pair. You must just be aware that the key have existed outside of its secure container and the risk that it is stolen exists.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • Of course, if availability is increased, so is attack surface. However, if I keep my backup key in a safe in a bank, then I would consider it to be in a safer spot than the one I actively use. –  Feb 10 '21 at 11:28
  • @MechMK1: not only the backup key is to be considered, but also the system where the key pair was generated... But I would not blame you for accepting that risk :-) – Serge Ballesta Feb 10 '21 at 14:09