11 ms·

Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? I would love to move from Username + Password + TOTP but

by aftbit 5y ago

Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? I would love to move from Username + Password + TOTP but my current workflow requires that I am able to regain access to my digital accounts using nothing but a few page paper backup including core service passwords & exported TOTP secrets.

zozbot234 5y ago
Is this actually needed? Looks like the online part of this is just WebAuthn, which could be supported by the same tools we use for TOTP. You would "enroll" a visible master secret that you could then back up and optionally store in a hardware security key. The device itself wouldn't need to allow for extracting the secret again, because you backed it up at enrollment.
- lrvick 5y ago
  Ledger and similar hardware wallets support one time BIP39 backup covering all current and future accounts today.
jupp0r 5y ago
Yubikey recommends a backup key for that very reason. Most providers allow you to register multiple keys.
- jedberg 5y ago
  While it's not a bad idea, I'm pretty sure Yubikey recommends a backup key so that they can sell twice as many Yubikeys.
- Zamicol 5y ago
  "providers allow you to register multiple keys" Why isn't my identity just a Merkle root? I don't understand the need to register individual keys.
  - giaour 5y ago
    You'd also need some way to revoke keys signed by the root if a valid hardware key were lost, stolen, or confiscated. I think Yubico will actually do something like this for large enough customers, though revocation is left as an exercise for the customer. When I worked for AWS, I was issued a couple company YubiKeys, and there was a web portal where I could revoke a token's association with my account.
  - lxgr 5y ago
    How would you add a new key at a later point in time (i.e. after your initial registration of e.g. a main and a backup key, after having lost the main key and wanting to add a new backup/main key)? The FIDO/WebAuthN model does by design not include a stateful/centralized authority that could maintain the required state for any such solution.
- kayodelycaon 5y ago
  And where do you store the backup key?
  - graton 5y ago
    In each one of my PCs and also on my key-ring is how I do it.
    - kayodelycaon 5y ago
      If you sign up using one key, do the other keys work with that account? Unless it does, you're greatly increasing the complexity of creating new accounts anywhere. That's basically what I'm getting at. Do I need to do significant amounts of extra work to keep an off-site backup in another state?
      - graton 5y ago
        I don't personally consider it greatly increasing complexity. At account creation I register the Yubikeys at the PC and on my keyring. When I first login from a different PC I use the Yubikey from my keyring to login and then register the Yubikey at this new PC.
    - tadfisher 5y ago
      Sounds like we should be doing FIDO with TPM then.
    - howinteresting 5y ago
      Sounds miserable compared to using a password manager.
  - jupp0r 4y ago
    Next to your birth certificate
- MrStonedOne 5y ago
  Yep! Just store your backup key in a safe-deposit box with your bank. Then go get it every time you sign up for a new account so you can make it the backup for that account then go store it again. and again. and again. and again. oh no! you lost your key! time to go to the bank to get your backup, sign in to all the accounts, remove the old key, register a new backup, oh wait, got to wait for the new backup to ship, so i guess you can't do that yet. hope you don't lose your key in the meantime, anywho, time to spend a few hours painstakingly removing your lost key from all the 9 thousand sites you use. yay! its a week to a month later, you finally got your new yubikey shipped, time to go log into to 9 thousand websites again to set it up as the backup for all of the sites. Ok, time to take it down to the bank. whats this? a cool new app my friend wants to show me, ok, time to go drive to the bank and get my backup key out of storage and sign up for this cool new app. You know, this whole driving to the bank thing, its kinda inconvenient, maybe i should just store it in my closet safe. What do you mean the gas line under my house exploded? but both my yubikeys are in there! ---- The above is fiction, and even under fiction it seems ridiculous how this would really go is even worse: "Go get my backup key to use for this new app my friend showed me? fuck that" . . "What do you mean i can't reset my password, but i lost my yubikey!" "No, i didn't want to get up to grab my backup token when i was registering." "Oh wait! i bet i still have the recovery codes as a pdf in my downloads folder. its a good thing no viruses ever think to look in there" ----
  - lrvick 5y ago
    There is no need for your described complexity. More advanced FIDO devices like the Ledger allow you to backup the initial random seed allowing you to create a duplicate device from the backup any time you wish. No sites you signed up with will know or care that you swapped devices as the new device will generate identical keys via a deterministic KDF from the seed. You can put this seed far away and would only ever need it when you wish to replace a lost or broken authentication device. Aside: no US major banks issue safety deposit boxes anymore other than wells fargo which will stop issuing them soon as well.
- markatto 5y ago
  I use the "multiple security keys" approach, and the biggest problem is keeping track of which keys are registered with which services and making sure the list is up to date. A few examples of situations where this is a problem: 1) I don't keep all of my keys on my person, so if I want to sign up for a service when I'm not at home, I have to remember to go back and add my other keys at a later time. If I wanted to, for example, keep a backup key in an offsite location such as a safe deposit box, this would be even more painful. 2) If I lose a key, I need to go and change every service to deactivate the lost key and add my replacement key. This is both time-consuming and error-prone, as it requires me to keep a full list of providers that I use keys with somewhere. 3) Some providers do not even allow you to register multiple keys.
  - jupp0r 5y ago
    The way it’s meant to be done: 1. You register both the primary and the backup key with every identity provider (ie GitHub) 2. You only carry the primary key with you at all times. You keep the backup key in a physically safe space (ie next to your birth certificate). 3. In case the primary key gets lost, you make the backup key your new primary key. You can log in with it everywhere because you already registered it in step 1. 4. You order a new key which will become your new backup key. 5. Go to step 1.
- nybble41 5y ago
  A backup key is a good idea, but there needs to be a way to enroll the backup key for a new account (ideally automatically) without the key being physically present, since otherwise you can't (practically) store the backup key off-site. To this end, you should be able to enroll a key using only the public part of the keypair.
  - sdfgdfgbsdfg 5y ago
    https://www.yubico.com/blog/yubico-proposes-webauthn-protocol-extension-to-simplify-backup-security-keys/ https://www.yubico.com/blog/yubico-proposes-webauthn-protoco... is a solution for that
traceroute66 5y ago
> Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? Why would you need that ? On most services that I use that support FIDO, you can register as many keys as you like. Seems to me that is a much more secure option than to provide a potentially exploitable option of allowing key extraction.
- li2uR3ce 5y ago
  I want to avoid having to fetch my backup key every time I want to setup a new account. The backup key is kept offsite and thus inconvenient. It's offsite because that protects me from fire or other such catastrophic events. This is what keeps me preferring password based security because I can backup my encrypted password database offsite with ease. Everything else provides hard path to recovery.
  - traceroute66 5y ago
    > I want to avoid having to fetch my backup key every time I want to setup a new account. The backup key is kept offsite and thus inconvenient. As stated, you can have as many backup keys as you like. Thus you are not limited to two keys. Buy one more key. Keep one off-site and two on-prem. Rotate them once in a while to keep the off-site one fresh.
    - zozbot234 5y ago
      > As stated, you can have as many backup keys as you like. That does not solve anything unless the backup keys are enrolled to each and every one of the services you use. Adding more backup keys and storing them more and more securely just makes it harder to be sure that you've enrolled them all to the latest service. This is not an issue if users are explicitly allowed to enroll "virtual" soft authenticators that they can back up and restore as they see fit, but that's an additional requirement that comes at some compromise, since some services might instead want to ensure that you're enrolling a non-cloneable credential. (E.g. your physical bank or non-remote employer, that can easily verify your identity via additional means if needed to restore your access.) The WebAuthn spec allows for both models.
pat2man 5y ago
Ledger (https://www.ledger.com https://www.ledger.com) supports FIDO and lets you do backups. You really need a screen to do it correctly, otherwise there is little point in having an external device.
- diggernet 5y ago
  TacticalCoder has previously commented here (https://news.ycombinator.com/item?id=26844019 https://news.ycombinator.com/item?id=26844019) about the ability to set a specific seed on Ledger devices, so you can make a backup key that behaves identically to your main key.
- lxgr 5y ago
  This might be true for cryptocurrency transaction initiation, but in the WebAuthN model, what's the benefit of having a screen? The result of a WebAuthN challenge procedure is almost always a session cookie (TLS channel binding if you're really fancy), so the only thing that an authenticator could display on your screen is "do you want to authenticate as user x to website y", which arguably does not add that much value.
  - tialaramex 5y ago
    The comment you're replying to is about cloning WebAuthn credentials. This is a delicate operation, because you are effectively cloning your entire identity. So yeah, a screen seems reasonable for that purpose.
  - nybble41 5y ago
    > … so the only thing that an authenticator could display on your screen is "do you want to authenticate as user x to website y" … That is exactly why you want it. Consider, for a moment, that you have a key which is used to log in to your bank account and some other, much less critical site. Perhaps a GitHub account where you store some hobby projects. Without an unforgeable indication on the authenticator to show what you're logging in to, malware can wait until you're logging in to the second site, and thus expecting a prompt to use the authenticator, but actually trigger the authentication process for your bank off-screen. You tap the button or whatever on the authenticator thinking that you're logging in to your GitHub account but actually all your money is being siphoned off to who-knows-where. A key that signs whatever request is presented to it without any indication to the user of what the request actually was is dangerous.
gazby 5y ago
Just so you don't feel alone with the replies being of the typical variety, I'm 100% with you. The flaws in the "backup token" approach are rehashed constantly but the world keeps turning as though they're irrelevant. I look forward to hardware tokens reaching a popularity level where we see implementations in software and this conversation can be rendered moot. Shout out to Mozilla and Dan Stiner for their work so far.
- zozbot234 5y ago
  Software ("virtual") implementations are already possible in WebAuthn. It's up to the service whether to allow enrollment via a software authenticator; most services will want to allow this, seeing as it's still way more secure than ordinary username/password.
  - throw1138 5y ago
    Are there any existing implementations I should be aware of?
    - md_ 5y ago
      https://github.com/danstiner/rust-u2f https://github.com/danstiner/rust-u2f https://github.com/google/OpenSK https://github.com/google/OpenSK
      - sodality2 5y ago
        OpenSK is mainly intended for flashing onto a device like a nordic dongle.
  - throwaway52022 5y ago
    For web apps/services, the browser needs to be involved here too, right? (And maybe the OS?) How can I tell Chrome on my desktop to use my "software token" instead of Chrome looking for a hardware token over USB or finding it via NFC, so the remote service can ultimately interact with my (virtual) token? (I don't even want to think about how to tell Mobile Safari on my iPhone how to find my key) EDIT: My ideal setup, I think, is an app on my phone that I can use as my token - somehow signaling to my desktop/laptop that it's nearby and can be used as a token and ideally popping up a notice on the phone lock screen when there's an authentication request so I can quickly get to it. Then in my app, I'm free to export and backup my keys for all of the sites I'm enrolled with as I see fit. I know, I know, maybe being able to export the keys makes the setup less secure, but I will trust myself not to accidentally give the backup to a phishing site. (And I do worry that I'll accidentally get phished using a TOTP app, so I'd like to switch to FIDO, but I don't want the pain of multiple keys)
NovemberWhiskey 5y ago
By design, ideally not. WebAuthn optionally includes (as a 'SHOULD') a signature counter concept that allows relying parties to be confident that the attestation isn't coming from a previously-cloned version of the authenticator.
- zozbot234 5y ago
  The specification states that cloning should merely be included in the service's underlying threat model. E.g. you might well be able to log in from an authenticator that fails the "signature counting" step if it's expected that the authenticator would allow for backing up and restoring its stored credentials.
  - NovemberWhiskey 5y ago
    I think the point is it's up to the relying party to make the decision; so an uneven user experience is possible.
    - zozbot234 5y ago
      If an "insecure" authenticator reveals itself at enrollment, the only "unevenness" is that attempts to enroll it might fail, perhaps with a request to use a securely attested authenticator instead - you would never be locked out from any service after the fact. This is better than "cloning" a supposedly secure device and then failing a count check while trying to authenticate.
      - NovemberWhiskey 5y ago
        Yeah; being told "you can't use that here" for some sites is a pretty uneven user experience, wouldn't you say? Not sure why the scare quotes are necessary here.
password4321 5y ago
There are some software tokens (Wear OS watch, Android phone), but they are purposely not exportable from the Android Keystore. https://github.com/herrjemand/awesome-webauthn#software-authenticators https://github.com/herrjemand/awesome-webauthn#software-auth... There was mention of a secure backup proposal, but it doesn't appear to have been touched after being a draft for a year: https://github.com/Yubico/webauthn-recovery-extension https://github.com/Yubico/webauthn-recovery-extension
- lrvick 5y ago
  Devices like Ledger already have seed phrase backup/restore via BIP39, but this is only safe or practical on devices with a screen which Yubico is very adamantly against ever supporting.
deleted 5y ago
[deleted]
vngzs 5y ago
With a sufficiently programmable hardware key, yes, you can back up the secrets. See an enumeration of methods in [0]. Be careful if you plan on doing this; make sure the tradeoffs make sense to you. You probably want to do the programming from an airgapped, trustworthy Linux machine. Beware that if you do this and lose your primary key, or if it is stolen, then an attacker can impersonate you. Setting up multiple unique keys is probably more useful in general, even if it's more cumbersome. [0]: https://dmitryfrank.com/articles/backup_u2f_token https://dmitryfrank.com/articles/backup_u2f_token
rdl 5y ago
Ideally there would be a way to create "tickets" or something from an authenticator in advance and then use them for registration without physical access to the device. Then I could have 100 tickets from my backup on my master, keep the physical backup in a secure offsite location, and enroll new services using master + backup-tickets. When I run out of tickets, generate 100 more. Being able to export/back up/restore master secrets would be nice too.
- tadfisher 5y ago
  This sounds suspiciously like PGP subkeys. Having not read into how FIDO works, I'm going to now assume it works by supplying a "public key" to a third party, and the third party authenticates by having you encrypt a nonce with a private key. How far off am I?
  - est31 5y ago
    FIDO involves creating a new public/private key pair for each website, to prevent cross website tracking. The keys are derived from a secret stored on the device, so the device doesn't need to store anything but that secret, which enables it to be used with a limitless number of websites. Edit: there seems to have been a paper that studied the very question of "can you create keys asynchronously so that you can later use them with a backup key": https://eprint.iacr.org/2020/1004.pdf https://eprint.iacr.org/2020/1004.pdf https://www.youtube.com/watch?v=urJ2DhpLAEk https://www.youtube.com/watch?v=urJ2DhpLAEk I need to read the paper however on how feasible an implementation of this is, and how much buy-in it needs from website and browser vendors.
  - lxgr 5y ago
    Cryptographically speaking it's signing a challenge, not encrypting a value (which would be a public key operation), but generally speaking yes, that's the idea of it! One of the things FIDO adds beyond a protocol for "plain" hardware-generated and stored keys is the idea of attestation, i.e. authenticators being able to express statements like "keys can never leave this authenticator" or "this key requires PIN or fingerprint verification" – all assuming you do trust the manufacturer.
snarf21 5y ago
I wish FIDO was built into the phones (enclave) requiring a biometric and passcode. For 99% of users this would be superior to email/password and get rid of a lot of hacks/phishing. It doesn't require extra hardware to buy and simply requires a minor protocol update to have the challenge on a laptop/desktop show as a QR-code (or could be sent via BT). The mobile sends the response out of band to a destination set at creation. For users with a greater threat model (worry about enclave being hacked), they can use physical FIDO keys.
- amf12 5y ago
  > I wish FIDO was built into the phones (enclave) requiring a biometric and passcode Pixel 6 supports this (Titan Security Key built-in) , but only works with Google accounts I think. I hope more phones support this.
  - tialaramex 5y ago
    Not just Google accounts, most Pixel phones (I think I have a Pixel 2 here) do WebAuthn. I use it for GitHub (occasionally) and my private pastebin setup which is WebAuthn protected for ease of use - and I could use it for Facebook (but I never book faces on my phone) and other services. One bonus feature does need the Google account. If you're signing into say banana.example with WebAuthn, using Chrome on a PC, and Chrome can't see any FIDO authenticators plugged in, it will try your phone! It asks Google, hey, does this user have a phone (Chrome is signed in to your Google account) ? Google says yeah, they have "amf12's Pixel 6". The Chrome browser uses Bluetooth on the PC to say "Hey, amf12's Pixel 6 are you out there? Can you do WebAuthn?" if your phone hears the Bluetooth message it's like "Hi, amf12's Pixel 6 here. Standing ready to do WebAuthn" and then via the Google servers it's arranged that your login attempt on Chrome, on the PC, is proxied to the phone, where it appears on screen ("Do you want to log in to banana.example as amf12?") and you can OK that from the phone. Nice work flow actually, although the technology is remarkably complicated.
- dwaite 5y ago
  The proposal here is using iCloud Keychain, leveraging the secure enclave. The only catch (for some security-minded, a bit one) is that iCloud Keychain acts similar to a resizable HSM cluster.
_vdpp 5y ago
I think the whole point of HSMs is that you can’t back up (read: exfiltrate) the master secrets. Having said that, on certain Yubikeys you can store PGP keys on them, and put the same secret key on several different Yubis. If you’re relying on a hardware key it’s probably a good idea to have a backup key and make sure both are registered with whatever system you’re accessing. LastPass and GitHub at least support adding several different security keys.
- sheerun 5y ago
  A backup key could have ability to reject original one, problem solved...
  - lxgr 5y ago
    How would that work in practice? Key/certificate revocation is notoriously hard.
    - withinboredom 5y ago
      With GitHub, you just remove it from your account. For 2fa, same story.
    - sdfgdfgbsdfg 5y ago
      Here's how YubiCo proposes to address this: https://www.yubico.com/blog/yubico-proposes-webauthn-protocol-extension-to-simplify-backup-security-keys/ https://www.yubico.com/blog/yubico-proposes-webauthn-protoco... Revocation is done RP side, but it essentially allows a primary authenticator to register itself and the secondary on a given RP
- lxgr 5y ago
  You'll need to generate the key on a less secure host to do that, though, which partially defeats the purpose of a hardware key in the first place. As far as I understand, "real" HSMs (i.e. the expensive, rack sized type of security key) sometimes offer the ability to export their root key to other models by the same manufacturer using a specific ceremony. Arguably this also significantly weakens the security of the keys protected in the HSM, but at least it does not automatically expose it to software.
deleted 5y ago
[deleted]
mmis1000 5y ago
I think FIDO is not meant to be backup at first place. It's more a derived key exists to authenticate certain device safely without being stolen to authenticate other you aren't expected. Make it easily backupable actually defeats its whole purpose if it is intended to be used this way. And for service that actually want it to be used as major key. I think they can just make the one authenticated able to authenticate another(and even decide whether this new device can auth yet another or not). (Like the way google use: popup on user phone, and ask if user would like to let the computer login.) I think the one we actually need is a common protocol to authenticate new fido device from existing one. Although you can do it currently, every website have different flow to do it. And there is not currently a common way here. A common and machine understandable way to auth new device from existing one may ease the pain.
- lxgr 5y ago
  At least the WebAuthN standard seems to be moving in a different direction [1], which is also surprising to me. In a nutshell, it will be possible for relying parties (i.e. websites) to detect multi-device/backup capable authenticators if required, but disabling multi-device functionality would require a very explicit opt-out, not an opt-in, on the relying party's side. [1] https://github.com/w3c/webauthn/issues/1714 https://github.com/w3c/webauthn/issues/1714
  - mmis1000 5y ago
    That seems to make fido just a non human readable/rememberable account/password. A somewhat downgrade from original hardware enforced implementation. But also make it more usable to majority of people, because keep something without losing it is just a pain to many people(where is my fxxking key goes again?). And it is still 1000x better than people using same password on every website.
    - lxgr 5y ago
      It's much more than a non-rememberable password: One of the most important attributes of WebAuthN/FIDO is that it's fundamentally impossible to fall victim to phishing. Assuming your browser isn't itself compromised, it is impossible to authenticate using a key for service.com on evil.com. Passwords can't do that. (PAKEs or other challenge/response protocols theoretically could, if implemented in the browser and not on websites, but that's a different story.)
eikenberry 5y ago
Yes there are. FIDO specifies different authentication levels and level 1 allows access to the master keys (it allows for pure software implementations). I think this page gives a decent overview of the levels... https://fidoalliance.org/certification/authenticator-certification-levels/ https://fidoalliance.org/certification/authenticator-certifi...
dwaite 5y ago
The vendors here are proposing a platform synchronization method such that these are both backed up as well as shared across devices within a particular platform account. There likely is a hardware key that supports export and import of keys (even if that winds up being a fork of say the Solo key firmware). However, as an end-user one doesn't want to accidentally forget to export keys for a while, nor do they want to worry about how to properly secure a backup. So, you likely would want additional infrastructure such as vendor software which would do this for you on a schedule. There are interesting models which could work here, such as a factory-paired 'set' of keys being sold in the same package, where only the second key (the one you kept in your fire safe) has the necessary keys to decrypt and load such a backup. The question is whether a security manufacturer would be interested in this, as the presence of such a mechanism may prevent them from getting certain security certifications and being able to sell/be used in certain markets and scenarios.
- blep_ 5y ago
  FIDO, at least, doesn't store per-site keys on the device. You only have to back up and restore the master key, which doesn't change and so doesn't need to be scheduled.
  - dwaite 5y ago
    When generating non-resident/non-discoverable credentials, many authenticators will use a source of randomness, an internal secret and possibly the name of the requesting origin to generate a private key, and export either a seed value or a wrapped version of that key in a 'credential handle' during registration. You have to pass that handle back to authenticate someone, which the authenticator will process and check to see if they were the one that issued it. Such credentials are only usable for secondary factors, because you need to know what list of registered handles to pass to the authenticator, which means you will typically need to know who the requesting party is. Web Authentication and CTAP 2.x added the notion of discoverable credentials, which do not require such handles and as such are usable as a primary factor for authentication. A site can simply ask into the void "do you have any credentials for example.com" and potentially get back an answer. These necessarily require state. Several of the platforms do not want to deal with the security ramifications of exporting wrapped keys, and simply generate and store keys even in the traditional U2F case. This is actually why the terminology was changed from 'resident' to 'discoverable' in WebAuthn L2 and CTAP 2.1 - a non-discoverable credential has the old behavior where you have to supply the handle to get back a response, but there's no guarantee that credential won't be resident in some state store of the authenticator.
TacticalCoder 5y ago
> Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? Yup there are for sure, for I tried it and it works. Now: I tried it out of curiosity and I'm not actually using it atm, so I don't where it's at but... I tried on Ledger hardware wallets (stuff meant for cryptocurrencies, but I tried them precisely for the U2F app): initialize the device with a seed of my own and then register to FIDO2/U2F/webauthn sites. Worked fine. Took a second hardware wallet, initialized it with the exact same seed: boom, it's working fine and I could login using that 2nd HSM device as the 2FA. Note that as soon as I used the 2nd device, the first one wasn't working anymore: if I wanted it to work again, I'd need to reinstall the U2F app on the HSM device (the way the device work is it only accepts apps that are signed, and that is enforced by the HSM itself: the HSM has the public key of the Ledger company so it can only install "apps", like the U2F app, that is actually signed by Ledger... I'm not saying that's 100% foolproof, but it's not exactly the most hackable thing on earth either). The reason you cannot use both devices at once is because of how an increment number is used: it has to be monotonicaly increasing and when the app is installed on the HSM, it uses the current time to initialize its counter. I haven't checked these lately: I know the specs evolved and I know Ledger said they were coming with a new U2F app but I didn't follow the latest developments. Still: I 100% confirm you that it's not only doable but it's actually been done.
- TacticalCoder 5y ago
  > requires that I am able to regain access to my digital accounts using nothing but a few page paper backup including core service passwords & exported TOTP secrets. EDIT: you basically save a 256 master seed as a list of 24 words (out of a fixed dictionary of precisely 2048 words, so 11 bits of entropy per number). 264 bits altogether: last word contains 3 bits par of the seed and 8 bits of checksum. Trivial to write down. Very little chance of miswriting it for: a) you must prove to the HSM you wrote your seed down correctly and b) the dictionary is known and hardly any word can be mistaken for another.
deleted 5y ago
[deleted]
lrvick 5y ago
Hardware wallets like a Ledger allow you only once, on initialization, to backup the initial random seed to paper in the form of 24 english words via the BIP39 standard. You can use this seed by hand or on a duplicate device to deterministically recreate all keys be they webauthn, pgp, bitcoin, or otherwise.
deleted 5y ago
[deleted]
WhyNotHugo 5y ago
You can have a backup key and keep it off-site (e.g.: at a family member's place). If you lose your main key, you can resort to that one to re-gain access. Keys that allow backing up the secret material are tricky, since they could potentially be cloned and someone would have a backdoor with you being unable to know of it.
password4321 4y ago
"Backing up" only, no restore (circa 2016): Decrypt/Extract NitroKey HSM RSA Private Keys https://news.ycombinator.com/item?id=12068858 https://news.ycombinator.com/item?id=12068858

by aftbit 5y ago

zozbot234 5y ago

Is this actually needed? Looks like the online part of this is just WebAuthn, which could be supported by the same tools we use for TOTP. You would "enroll" a visible master secret that you could then back up and optionally store in a hardware security key. The device itself wouldn't need to allow for extracting the secret again, because you backed it up at enrollment.

lrvick 5y ago
Ledger and similar hardware wallets support one time BIP39 backup covering all current and future accounts today.

jupp0r 5y ago

Yubikey recommends a backup key for that very reason. Most providers allow you to register multiple keys.

jedberg 5y ago
While it's not a bad idea, I'm pretty sure Yubikey recommends a backup key so that they can sell twice as many Yubikeys.
Zamicol 5y ago
"providers allow you to register multiple keys" Why isn't my identity just a Merkle root? I don't understand the need to register individual keys.
- giaour 5y ago
  You'd also need some way to revoke keys signed by the root if a valid hardware key were lost, stolen, or confiscated. I think Yubico will actually do something like this for large enough customers, though revocation is left as an exercise for the customer. When I worked for AWS, I was issued a couple company YubiKeys, and there was a web portal where I could revoke a token's association with my account.
- lxgr 5y ago
  How would you add a new key at a later point in time (i.e. after your initial registration of e.g. a main and a backup key, after having lost the main key and wanting to add a new backup/main key)? The FIDO/WebAuthN model does by design not include a stateful/centralized authority that could maintain the required state for any such solution.
kayodelycaon 5y ago
And where do you store the backup key?
- graton 5y ago
  In each one of my PCs and also on my key-ring is how I do it.
  - kayodelycaon 5y ago
    If you sign up using one key, do the other keys work with that account? Unless it does, you're greatly increasing the complexity of creating new accounts anywhere. That's basically what I'm getting at. Do I need to do significant amounts of extra work to keep an off-site backup in another state?
    - graton 5y ago
      I don't personally consider it greatly increasing complexity. At account creation I register the Yubikeys at the PC and on my keyring. When I first login from a different PC I use the Yubikey from my keyring to login and then register the Yubikey at this new PC.
  - tadfisher 5y ago
    Sounds like we should be doing FIDO with TPM then.
  - howinteresting 5y ago
    Sounds miserable compared to using a password manager.
- jupp0r 4y ago
  Next to your birth certificate
MrStonedOne 5y ago
Yep! Just store your backup key in a safe-deposit box with your bank. Then go get it every time you sign up for a new account so you can make it the backup for that account then go store it again. and again. and again. and again. oh no! you lost your key! time to go to the bank to get your backup, sign in to all the accounts, remove the old key, register a new backup, oh wait, got to wait for the new backup to ship, so i guess you can't do that yet. hope you don't lose your key in the meantime, anywho, time to spend a few hours painstakingly removing your lost key from all the 9 thousand sites you use. yay! its a week to a month later, you finally got your new yubikey shipped, time to go log into to 9 thousand websites again to set it up as the backup for all of the sites. Ok, time to take it down to the bank. whats this? a cool new app my friend wants to show me, ok, time to go drive to the bank and get my backup key out of storage and sign up for this cool new app. You know, this whole driving to the bank thing, its kinda inconvenient, maybe i should just store it in my closet safe. What do you mean the gas line under my house exploded? but both my yubikeys are in there! ---- The above is fiction, and even under fiction it seems ridiculous how this would really go is even worse: "Go get my backup key to use for this new app my friend showed me? fuck that" . . "What do you mean i can't reset my password, but i lost my yubikey!" "No, i didn't want to get up to grab my backup token when i was registering." "Oh wait! i bet i still have the recovery codes as a pdf in my downloads folder. its a good thing no viruses ever think to look in there" ----
- lrvick 5y ago
  There is no need for your described complexity. More advanced FIDO devices like the Ledger allow you to backup the initial random seed allowing you to create a duplicate device from the backup any time you wish. No sites you signed up with will know or care that you swapped devices as the new device will generate identical keys via a deterministic KDF from the seed. You can put this seed far away and would only ever need it when you wish to replace a lost or broken authentication device. Aside: no US major banks issue safety deposit boxes anymore other than wells fargo which will stop issuing them soon as well.
markatto 5y ago
I use the "multiple security keys" approach, and the biggest problem is keeping track of which keys are registered with which services and making sure the list is up to date. A few examples of situations where this is a problem: 1) I don't keep all of my keys on my person, so if I want to sign up for a service when I'm not at home, I have to remember to go back and add my other keys at a later time. If I wanted to, for example, keep a backup key in an offsite location such as a safe deposit box, this would be even more painful. 2) If I lose a key, I need to go and change every service to deactivate the lost key and add my replacement key. This is both time-consuming and error-prone, as it requires me to keep a full list of providers that I use keys with somewhere. 3) Some providers do not even allow you to register multiple keys.
- jupp0r 5y ago
  The way it’s meant to be done: 1. You register both the primary and the backup key with every identity provider (ie GitHub) 2. You only carry the primary key with you at all times. You keep the backup key in a physically safe space (ie next to your birth certificate). 3. In case the primary key gets lost, you make the backup key your new primary key. You can log in with it everywhere because you already registered it in step 1. 4. You order a new key which will become your new backup key. 5. Go to step 1.
nybble41 5y ago
A backup key is a good idea, but there needs to be a way to enroll the backup key for a new account (ideally automatically) without the key being physically present, since otherwise you can't (practically) store the backup key off-site. To this end, you should be able to enroll a key using only the public part of the keypair.
- sdfgdfgbsdfg 5y ago
  https://www.yubico.com/blog/yubico-proposes-webauthn-protocol-extension-to-simplify-backup-security-keys/ https://www.yubico.com/blog/yubico-proposes-webauthn-protoco... is a solution for that

traceroute66 5y ago

> Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? Why would you need that ? On most services that I use that support FIDO, you can register as many keys as you like. Seems to me that is a much more secure option than to provide a potentially exploitable option of allowing key extraction.

li2uR3ce 5y ago
I want to avoid having to fetch my backup key every time I want to setup a new account. The backup key is kept offsite and thus inconvenient. It's offsite because that protects me from fire or other such catastrophic events. This is what keeps me preferring password based security because I can backup my encrypted password database offsite with ease. Everything else provides hard path to recovery.
- traceroute66 5y ago
  > I want to avoid having to fetch my backup key every time I want to setup a new account. The backup key is kept offsite and thus inconvenient. As stated, you can have as many backup keys as you like. Thus you are not limited to two keys. Buy one more key. Keep one off-site and two on-prem. Rotate them once in a while to keep the off-site one fresh.
  - zozbot234 5y ago
    > As stated, you can have as many backup keys as you like. That does not solve anything unless the backup keys are enrolled to each and every one of the services you use. Adding more backup keys and storing them more and more securely just makes it harder to be sure that you've enrolled them all to the latest service. This is not an issue if users are explicitly allowed to enroll "virtual" soft authenticators that they can back up and restore as they see fit, but that's an additional requirement that comes at some compromise, since some services might instead want to ensure that you're enrolling a non-cloneable credential. (E.g. your physical bank or non-remote employer, that can easily verify your identity via additional means if needed to restore your access.) The WebAuthn spec allows for both models.

pat2man 5y ago

Ledger (https://www.ledger.com https://www.ledger.com) supports FIDO and lets you do backups. You really need a screen to do it correctly, otherwise there is little point in having an external device.

diggernet 5y ago
TacticalCoder has previously commented here (https://news.ycombinator.com/item?id=26844019 https://news.ycombinator.com/item?id=26844019) about the ability to set a specific seed on Ledger devices, so you can make a backup key that behaves identically to your main key.
lxgr 5y ago
This might be true for cryptocurrency transaction initiation, but in the WebAuthN model, what's the benefit of having a screen? The result of a WebAuthN challenge procedure is almost always a session cookie (TLS channel binding if you're really fancy), so the only thing that an authenticator could display on your screen is "do you want to authenticate as user x to website y", which arguably does not add that much value.
- tialaramex 5y ago
  The comment you're replying to is about cloning WebAuthn credentials. This is a delicate operation, because you are effectively cloning your entire identity. So yeah, a screen seems reasonable for that purpose.
- nybble41 5y ago
  > … so the only thing that an authenticator could display on your screen is "do you want to authenticate as user x to website y" … That is exactly why you want it. Consider, for a moment, that you have a key which is used to log in to your bank account and some other, much less critical site. Perhaps a GitHub account where you store some hobby projects. Without an unforgeable indication on the authenticator to show what you're logging in to, malware can wait until you're logging in to the second site, and thus expecting a prompt to use the authenticator, but actually trigger the authentication process for your bank off-screen. You tap the button or whatever on the authenticator thinking that you're logging in to your GitHub account but actually all your money is being siphoned off to who-knows-where. A key that signs whatever request is presented to it without any indication to the user of what the request actually was is dangerous.

gazby 5y ago

Just so you don't feel alone with the replies being of the typical variety, I'm 100% with you. The flaws in the "backup token" approach are rehashed constantly but the world keeps turning as though they're irrelevant. I look forward to hardware tokens reaching a popularity level where we see implementations in software and this conversation can be rendered moot. Shout out to Mozilla and Dan Stiner for their work so far.

zozbot234 5y ago
Software ("virtual") implementations are already possible in WebAuthn. It's up to the service whether to allow enrollment via a software authenticator; most services will want to allow this, seeing as it's still way more secure than ordinary username/password.
- throw1138 5y ago
  Are there any existing implementations I should be aware of?
  - md_ 5y ago
    https://github.com/danstiner/rust-u2f https://github.com/danstiner/rust-u2f https://github.com/google/OpenSK https://github.com/google/OpenSK
    - sodality2 5y ago
      OpenSK is mainly intended for flashing onto a device like a nordic dongle.
- throwaway52022 5y ago
  For web apps/services, the browser needs to be involved here too, right? (And maybe the OS?) How can I tell Chrome on my desktop to use my "software token" instead of Chrome looking for a hardware token over USB or finding it via NFC, so the remote service can ultimately interact with my (virtual) token? (I don't even want to think about how to tell Mobile Safari on my iPhone how to find my key) EDIT: My ideal setup, I think, is an app on my phone that I can use as my token - somehow signaling to my desktop/laptop that it's nearby and can be used as a token and ideally popping up a notice on the phone lock screen when there's an authentication request so I can quickly get to it. Then in my app, I'm free to export and backup my keys for all of the sites I'm enrolled with as I see fit. I know, I know, maybe being able to export the keys makes the setup less secure, but I will trust myself not to accidentally give the backup to a phishing site. (And I do worry that I'll accidentally get phished using a TOTP app, so I'd like to switch to FIDO, but I don't want the pain of multiple keys)

NovemberWhiskey 5y ago

By design, ideally not. WebAuthn optionally includes (as a 'SHOULD') a signature counter concept that allows relying parties to be confident that the attestation isn't coming from a previously-cloned version of the authenticator.

zozbot234 5y ago
The specification states that cloning should merely be included in the service's underlying threat model. E.g. you might well be able to log in from an authenticator that fails the "signature counting" step if it's expected that the authenticator would allow for backing up and restoring its stored credentials.
- NovemberWhiskey 5y ago
  I think the point is it's up to the relying party to make the decision; so an uneven user experience is possible.
  - zozbot234 5y ago
    If an "insecure" authenticator reveals itself at enrollment, the only "unevenness" is that attempts to enroll it might fail, perhaps with a request to use a securely attested authenticator instead - you would never be locked out from any service after the fact. This is better than "cloning" a supposedly secure device and then failing a count check while trying to authenticate.
    - NovemberWhiskey 5y ago
      Yeah; being told "you can't use that here" for some sites is a pretty uneven user experience, wouldn't you say? Not sure why the scare quotes are necessary here.

password4321 5y ago

There are some software tokens (Wear OS watch, Android phone), but they are purposely not exportable from the Android Keystore. https://github.com/herrjemand/awesome-webauthn#software-authenticators https://github.com/herrjemand/awesome-webauthn#software-auth... There was mention of a secure backup proposal, but it doesn't appear to have been touched after being a draft for a year: https://github.com/Yubico/webauthn-recovery-extension https://github.com/Yubico/webauthn-recovery-extension

lrvick 5y ago
Devices like Ledger already have seed phrase backup/restore via BIP39, but this is only safe or practical on devices with a screen which Yubico is very adamantly against ever supporting.

deleted 5y ago

[deleted]

vngzs 5y ago

With a sufficiently programmable hardware key, yes, you can back up the secrets. See an enumeration of methods in [0]. Be careful if you plan on doing this; make sure the tradeoffs make sense to you. You probably want to do the programming from an airgapped, trustworthy Linux machine. Beware that if you do this and lose your primary key, or if it is stolen, then an attacker can impersonate you. Setting up multiple unique keys is probably more useful in general, even if it's more cumbersome. [0]: https://dmitryfrank.com/articles/backup_u2f_token https://dmitryfrank.com/articles/backup_u2f_token

rdl 5y ago

Ideally there would be a way to create "tickets" or something from an authenticator in advance and then use them for registration without physical access to the device. Then I could have 100 tickets from my backup on my master, keep the physical backup in a secure offsite location, and enroll new services using master + backup-tickets. When I run out of tickets, generate 100 more. Being able to export/back up/restore master secrets would be nice too.

tadfisher 5y ago
This sounds suspiciously like PGP subkeys. Having not read into how FIDO works, I'm going to now assume it works by supplying a "public key" to a third party, and the third party authenticates by having you encrypt a nonce with a private key. How far off am I?
- est31 5y ago
  FIDO involves creating a new public/private key pair for each website, to prevent cross website tracking. The keys are derived from a secret stored on the device, so the device doesn't need to store anything but that secret, which enables it to be used with a limitless number of websites. Edit: there seems to have been a paper that studied the very question of "can you create keys asynchronously so that you can later use them with a backup key": https://eprint.iacr.org/2020/1004.pdf https://eprint.iacr.org/2020/1004.pdf https://www.youtube.com/watch?v=urJ2DhpLAEk https://www.youtube.com/watch?v=urJ2DhpLAEk I need to read the paper however on how feasible an implementation of this is, and how much buy-in it needs from website and browser vendors.
- lxgr 5y ago
  Cryptographically speaking it's signing a challenge, not encrypting a value (which would be a public key operation), but generally speaking yes, that's the idea of it! One of the things FIDO adds beyond a protocol for "plain" hardware-generated and stored keys is the idea of attestation, i.e. authenticators being able to express statements like "keys can never leave this authenticator" or "this key requires PIN or fingerprint verification" – all assuming you do trust the manufacturer.

snarf21 5y ago

I wish FIDO was built into the phones (enclave) requiring a biometric and passcode. For 99% of users this would be superior to email/password and get rid of a lot of hacks/phishing. It doesn't require extra hardware to buy and simply requires a minor protocol update to have the challenge on a laptop/desktop show as a QR-code (or could be sent via BT). The mobile sends the response out of band to a destination set at creation. For users with a greater threat model (worry about enclave being hacked), they can use physical FIDO keys.

amf12 5y ago
> I wish FIDO was built into the phones (enclave) requiring a biometric and passcode Pixel 6 supports this (Titan Security Key built-in) , but only works with Google accounts I think. I hope more phones support this.
- tialaramex 5y ago
  Not just Google accounts, most Pixel phones (I think I have a Pixel 2 here) do WebAuthn. I use it for GitHub (occasionally) and my private pastebin setup which is WebAuthn protected for ease of use - and I could use it for Facebook (but I never book faces on my phone) and other services. One bonus feature does need the Google account. If you're signing into say banana.example with WebAuthn, using Chrome on a PC, and Chrome can't see any FIDO authenticators plugged in, it will try your phone! It asks Google, hey, does this user have a phone (Chrome is signed in to your Google account) ? Google says yeah, they have "amf12's Pixel 6". The Chrome browser uses Bluetooth on the PC to say "Hey, amf12's Pixel 6 are you out there? Can you do WebAuthn?" if your phone hears the Bluetooth message it's like "Hi, amf12's Pixel 6 here. Standing ready to do WebAuthn" and then via the Google servers it's arranged that your login attempt on Chrome, on the PC, is proxied to the phone, where it appears on screen ("Do you want to log in to banana.example as amf12?") and you can OK that from the phone. Nice work flow actually, although the technology is remarkably complicated.
dwaite 5y ago
The proposal here is using iCloud Keychain, leveraging the secure enclave. The only catch (for some security-minded, a bit one) is that iCloud Keychain acts similar to a resizable HSM cluster.

_vdpp 5y ago

I think the whole point of HSMs is that you can’t back up (read: exfiltrate) the master secrets. Having said that, on certain Yubikeys you can store PGP keys on them, and put the same secret key on several different Yubis. If you’re relying on a hardware key it’s probably a good idea to have a backup key and make sure both are registered with whatever system you’re accessing. LastPass and GitHub at least support adding several different security keys.

sheerun 5y ago
A backup key could have ability to reject original one, problem solved...
- lxgr 5y ago
  How would that work in practice? Key/certificate revocation is notoriously hard.
  - withinboredom 5y ago
    With GitHub, you just remove it from your account. For 2fa, same story.
  - sdfgdfgbsdfg 5y ago
    Here's how YubiCo proposes to address this: https://www.yubico.com/blog/yubico-proposes-webauthn-protocol-extension-to-simplify-backup-security-keys/ https://www.yubico.com/blog/yubico-proposes-webauthn-protoco... Revocation is done RP side, but it essentially allows a primary authenticator to register itself and the secondary on a given RP
lxgr 5y ago
You'll need to generate the key on a less secure host to do that, though, which partially defeats the purpose of a hardware key in the first place. As far as I understand, "real" HSMs (i.e. the expensive, rack sized type of security key) sometimes offer the ability to export their root key to other models by the same manufacturer using a specific ceremony. Arguably this also significantly weakens the security of the keys protected in the HSM, but at least it does not automatically expose it to software.

deleted 5y ago

[deleted]

mmis1000 5y ago

I think FIDO is not meant to be backup at first place. It's more a derived key exists to authenticate certain device safely without being stolen to authenticate other you aren't expected. Make it easily backupable actually defeats its whole purpose if it is intended to be used this way. And for service that actually want it to be used as major key. I think they can just make the one authenticated able to authenticate another(and even decide whether this new device can auth yet another or not). (Like the way google use: popup on user phone, and ask if user would like to let the computer login.) I think the one we actually need is a common protocol to authenticate new fido device from existing one. Although you can do it currently, every website have different flow to do it. And there is not currently a common way here. A common and machine understandable way to auth new device from existing one may ease the pain.

lxgr 5y ago
At least the WebAuthN standard seems to be moving in a different direction [1], which is also surprising to me. In a nutshell, it will be possible for relying parties (i.e. websites) to detect multi-device/backup capable authenticators if required, but disabling multi-device functionality would require a very explicit opt-out, not an opt-in, on the relying party's side. [1] https://github.com/w3c/webauthn/issues/1714 https://github.com/w3c/webauthn/issues/1714
- mmis1000 5y ago
  That seems to make fido just a non human readable/rememberable account/password. A somewhat downgrade from original hardware enforced implementation. But also make it more usable to majority of people, because keep something without losing it is just a pain to many people(where is my fxxking key goes again?). And it is still 1000x better than people using same password on every website.
  - lxgr 5y ago
    It's much more than a non-rememberable password: One of the most important attributes of WebAuthN/FIDO is that it's fundamentally impossible to fall victim to phishing. Assuming your browser isn't itself compromised, it is impossible to authenticate using a key for service.com on evil.com. Passwords can't do that. (PAKEs or other challenge/response protocols theoretically could, if implemented in the browser and not on websites, but that's a different story.)

eikenberry 5y ago

Yes there are. FIDO specifies different authentication levels and level 1 allows access to the master keys (it allows for pure software implementations). I think this page gives a decent overview of the levels... https://fidoalliance.org/certification/authenticator-certification-levels/ https://fidoalliance.org/certification/authenticator-certifi...

dwaite 5y ago

The vendors here are proposing a platform synchronization method such that these are both backed up as well as shared across devices within a particular platform account. There likely is a hardware key that supports export and import of keys (even if that winds up being a fork of say the Solo key firmware). However, as an end-user one doesn't want to accidentally forget to export keys for a while, nor do they want to worry about how to properly secure a backup. So, you likely would want additional infrastructure such as vendor software which would do this for you on a schedule. There are interesting models which could work here, such as a factory-paired 'set' of keys being sold in the same package, where only the second key (the one you kept in your fire safe) has the necessary keys to decrypt and load such a backup. The question is whether a security manufacturer would be interested in this, as the presence of such a mechanism may prevent them from getting certain security certifications and being able to sell/be used in certain markets and scenarios.

blep_ 5y ago
FIDO, at least, doesn't store per-site keys on the device. You only have to back up and restore the master key, which doesn't change and so doesn't need to be scheduled.
- dwaite 5y ago
  When generating non-resident/non-discoverable credentials, many authenticators will use a source of randomness, an internal secret and possibly the name of the requesting origin to generate a private key, and export either a seed value or a wrapped version of that key in a 'credential handle' during registration. You have to pass that handle back to authenticate someone, which the authenticator will process and check to see if they were the one that issued it. Such credentials are only usable for secondary factors, because you need to know what list of registered handles to pass to the authenticator, which means you will typically need to know who the requesting party is. Web Authentication and CTAP 2.x added the notion of discoverable credentials, which do not require such handles and as such are usable as a primary factor for authentication. A site can simply ask into the void "do you have any credentials for example.com" and potentially get back an answer. These necessarily require state. Several of the platforms do not want to deal with the security ramifications of exporting wrapped keys, and simply generate and store keys even in the traditional U2F case. This is actually why the terminology was changed from 'resident' to 'discoverable' in WebAuthn L2 and CTAP 2.1 - a non-discoverable credential has the old behavior where you have to supply the handle to get back a response, but there's no guarantee that credential won't be resident in some state store of the authenticator.

TacticalCoder 5y ago

> Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? Yup there are for sure, for I tried it and it works. Now: I tried it out of curiosity and I'm not actually using it atm, so I don't where it's at but... I tried on Ledger hardware wallets (stuff meant for cryptocurrencies, but I tried them precisely for the U2F app): initialize the device with a seed of my own and then register to FIDO2/U2F/webauthn sites. Worked fine. Took a second hardware wallet, initialized it with the exact same seed: boom, it's working fine and I could login using that 2nd HSM device as the 2FA. Note that as soon as I used the 2nd device, the first one wasn't working anymore: if I wanted it to work again, I'd need to reinstall the U2F app on the HSM device (the way the device work is it only accepts apps that are signed, and that is enforced by the HSM itself: the HSM has the public key of the Ledger company so it can only install "apps", like the U2F app, that is actually signed by Ledger... I'm not saying that's 100% foolproof, but it's not exactly the most hackable thing on earth either). The reason you cannot use both devices at once is because of how an increment number is used: it has to be monotonicaly increasing and when the app is installed on the HSM, it uses the current time to initialize its counter. I haven't checked these lately: I know the specs evolved and I know Ledger said they were coming with a new U2F app but I didn't follow the latest developments. Still: I 100% confirm you that it's not only doable but it's actually been done.

TacticalCoder 5y ago
> requires that I am able to regain access to my digital accounts using nothing but a few page paper backup including core service passwords & exported TOTP secrets. EDIT: you basically save a 256 master seed as a list of 24 words (out of a fixed dictionary of precisely 2048 words, so 11 bits of entropy per number). 264 bits altogether: last word contains 3 bits par of the seed and 8 bits of checksum. Trivial to write down. Very little chance of miswriting it for: a) you must prove to the HSM you wrote your seed down correctly and b) the dictionary is known and hardly any word can be mistaken for another.

deleted 5y ago

[deleted]

lrvick 5y ago

Hardware wallets like a Ledger allow you only once, on initialization, to backup the initial random seed to paper in the form of 24 english words via the BIP39 standard. You can use this seed by hand or on a duplicate device to deterministically recreate all keys be they webauthn, pgp, bitcoin, or otherwise.

deleted 5y ago

[deleted]

WhyNotHugo 5y ago

You can have a backup key and keep it off-site (e.g.: at a family member's place). If you lose your main key, you can resort to that one to re-gain access. Keys that allow backing up the secret material are tricky, since they could potentially be cloned and someone would have a backdoor with you being unable to know of it.

password4321 4y ago

"Backing up" only, no restore (circa 2016): Decrypt/Extract NitroKey HSM RSA Private Keys https://news.ycombinator.com/item?id=12068858 https://news.ycombinator.com/item?id=12068858