Another side. I always worry more about being locked out by 2FA (a main use case of non-discoverable FIDO keys) as a consequence of lost/retired-then-forgotten keys.

This happened once when the US custom detained my electronics, including a Yubikey. Later I managed to recover many accounts that accept email for 2FA or as the ultimate auth factor (i.e., password/2FA reset). But a few, including AWS, doesn't allow that.

Many websites encourage you to enroll 2FA without clarifying the alternative factors and the consequence of lost access.

> without clarifying the alternative factors

This is super annoying. I wish sites would standardize on a simple infographic saying:

You will be able to access your account with:

* Username, Password and 2FA device.

or

* 5 points from the following list: Username (1), Current password (2), old password (0.5), sms verification (1), mothers maiden name or other secret word (0.5). Email verification (2). 2 factor device (2), Video call with support agent showing government ID matching account name (1), has waited 7 days without successful login, despite notifying all contact addresses (2)

For added security, you can adjust the account to require 6, 7 or 8 points from the above list, but please be aware doing so might hinder your ability to access the account if you lose your password or 2FA device.

Unfortunately identity systems have adopted security through obscurity instead.

They use IP address, location, time since last login, number of attempts, device etc to determine how easy to make it for you to log in.

I lost a Gmail account because I no longer had an old phone number even though my password was correct.

The obscurity is that you have no idea what is required to log in.

> the US custom detained my electronics, including a Yubikey

Can you elaborate on what happened?

I know that it's theoretically possible, but I thought that:

1- They would potentially detain only devices that they can extract information out of (even if encrypted), like a laptop or some hard disk... Yubikey (at least the old U2F-only ones) don't have anything that you can extract

2- They would eventually return the device to you (unless guilty of some national security violation?)

Am I mistaken on both counts?

> 2- They would eventually return the device to you (unless guilty of some national security violation?)

"Eventually" is not good enough. People take things with them on their trips, because they expect to use these things while they are traveling/doing work at a remote location. Imagine you need to do some work on a remote site and you can't log in to your company's network, because the TSA has taken away your key so that they can inspect it.

For 1, tbh I don't know the rules. technically it was a regular model and can store some data. Or maybe they simply suspected it's a usb disk.

And 2 was true. But it was after weeks, and of course I didn't wait until then to reset my account credentials.

If they just seize it, it will typically be returned at some point. If they decide it's subject to forfeiture, it is now their property. You can contest this with the forfeiture department but I guess if they decide the item is guilty of a crime or other excuses to keep it there's nothing you can do.

That's right. It will be United States v. Some Person's Yubikey. And you can hire it a lawyer if you want, because they will NOT give it a public defender. Massive violation of Constitutional rights if you ask me.

> Yubikey (at least the old U2F-only ones) don't have anything that you can extract

Newer Yubikeys hold secrets that, if exfiltrated, give you access to accounts.

I assume that if it doesn't already exist, there will be a Cellebrite-like device that governments can plug Yubikeys into to dump keys quickly like they're able to with cell phones.

The entire point of Yubikeys is that such a device should be impossible, and vice versa, if such a device were to exist, the Yubikey is nothing but an expensive USB flash drive.

It should also be a dramatically smaller attack surface than a smartphone!

You should always have more than one 2FA. Especially for anything Google as you'll never ever recover the account (unless you are famous or go viral <1%).

There's a reason that Apple won't let you enable FIDO keys without having two of them to enroll.

> But a few, including AWS, doesn't allow that.

IAM users you are correct only allow a single 2fa key (their way of deprecating IAM users), but their SSO Users can have as many as they want and are honestly much better than IAM users. Even for my personal account I've moved to using an SSO User.

I don't think this is accurate - I have multiple MFA devices associated with all my AWS IAM users on multiple accounts of various ages.

AWS documentation specifies that users are allowed upto eight MFA devices each:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credenti...

Interesting, last I bothered with IAM users they were limited to a single MFA "device" virtual or otherwise.

https://aws.amazon.com/blogs/security/you-can-now-assign-mul...

Apparently I haven't bothered with them for a few months and didn't notice, glad they finally added it.

Oh I've either overlooked this too (2022, not just a few months) or there's some caveat like 'one of each type' or something.

Will have to try again. Presently have a user per key, named with the end of the keys ID so I know which to use, not brilliant but works.

Most sites let you print recovery keys.

Print those keys out, and bury them in the backyard (or something like that).

Or always add two keys.

>I don't remember where I've used my YubiKey in the past.

I track this in my password manager. Accounts where the YubiKey is enrolled are tagged "YubiKey (FIDO)".

This would probably be a good place to suggest to others here to track which accounts you've logged into via Google or other social media oath.

I just had to log into stack overflow for the first time in years, and did not remember what I used to previously log in. Once I figured it out that information went into Keepass too.

Just fyi, Google lists sites you’ve used to “sign in with Google” in your account setting page. Apple and GitHub have this as well.

You should assume Google, GitHub, and Apple are hostile and try to limit your blast radius. If you have an account problem they have no customer service to help you.

I can't get into my Google account that's almost 20 years old because I only have the username, password, recovery email and have all the email forwarded to me, but I no longer have the phone number and they silently enabled 2FA SMS at some point.

I wonder if you can phone the phone number, explain the situation and offer to venmo/paypal the new assignee money for the 2FA code

You could try every 3 - 5 years or so as it gets reassigned again

I tried this before, but I haven't tried for a couple of years -- you're right, it might have got reassigned -- I will try again!

+1

Yes, this is exactly why I won’t use these federated identity features of platforms like this. I have a reasonable amount of trust that they are mostly secure, but I have zero trust that they will be helpful if I ever have account troubles. What I don’t need is to have Google (etc) auth problems cascade down to every other account I own.

What's the alternative? What do you use for your base "recovery account" email?

My own domain’s email, which can easily be forwarded wherever I want.

Very well stated, concisely. Thank you.

Thank you, I should review that.

1Password has this functionality and it's excellent.

I really wish Bitwarden had more robust tools for organizing, sorting and tagging passwords. The current system of sorting them into folders is practically useless.

For sites that use a resident webauthn token like GitHub, you can list the known sites on the key. The UX for all this is not where it should be, however.

Are you sure that GitHub uses resident keys? I'm fairly sure they use non-resident keys.

They do now, but they didn't in the past.

Any idea why this was changed? The big advantage of non-residential keys is that they do not take up any space on the Fido token and thus you can have an unlimited number of them.

They wanted discoverable credentials to enable the magic username-less "sign in with passkey" auth flow.

I really couldn't care less about that. But I do care about the limited space on my fido token.

I've used five RK slots out of 25 available on my daily driver keys. Three of those are for SSO providers that provide access to the majority of the other apps I use. I opt in to "sign in with Google" etc wherever I can.

I don't see this impacting me personally anytime soon, but that might change when more sites start insisting on rolling their own RKs.

Hopefully future Yubikey models will ship with more flash, enabling many more RKs if you so desire.

I've always hated that I couldn't clone or backup my personal yubikey. It's one of the reasons I've avoided using it everywhere.

Good news then, since the article is discussing the discovery of that exact feature.

I mean, that's the security story around it. You solve this and buying multiple yubikeys. Google and others support multiple keys, which gives you the backup story (I have 4 keys in various places).

There's no fundamental reason it needs to be this difficult.

Yubico or really any other manufacturer could totally e.g. release "Yubikey pairs", both a stateless CTAP2 implementation with the same root secret, that would correspondingly work at the same sites without having to synchronize anything.

The reason they probably don't is that their entire trust model heavily depends on the perception that nobody, including the manufacturer, has a "reserve key" to any given Yubikey, even though of course the absence of such "linked keys" doesn't demonstrate the absence of any such backdoor.

To be clear, I don't have any reason to believe Yubico does this, but it would probably be a harder story to tell, marketing-wise, if they sometimes selectively did, even if it's for a valid use case.

I mean you could also design keys to be synchronisable by the user. Generate a key-pair inside of key (2), transfer the public key from (2) to (1). Encrypt the the root key inside of (1) with the public key, transfer it over to (2).

(Or just allow the user to generate the root key outside of the device and insert it)

I honestly think the interest from customers is just too low. I would bet the majority of Yubico's customers are enterprises where this is not really an issue for most use cases. If you loose your key used for Entra ID / SSO, just go to IT support and get a new one enrolled to your account. Much cheaper than having synchronised hot spares (at 30-50 USD a pop) for thousands of employees.

But what stops Mallory from simply using this sync method to sync your private key to her Yubikey? I mean, look at the kerfuffle that's been kicked up by this vulnerability, and a key-sharing scheme like the above is much easier to exploit.

(The second idea seems better assuming the user nukes the private key once the import is done. Otherwise the weakest link in the security chain will continue to be the opsec you practice with the private key file, in which case why spend the money on the Yubikey?)

Yeah of course the operation needs to be (cryptographically) authenticated somehow, I edited my comment in haste while going to work and accidentally messed it up completely. Thanks for pointing it out!

The idea I thought of is to essentially use the public key of (2) to seed the generation of the root secret on (1). Meaning the sync-pairing-setup is destructive to the root secret, and can only be done at startup (or if you are willing to reset the device).

(A mallory could of course reset it still, unless you have some e-fuse or something, but anyways that's only marginally worse than simply physically destroying it.)

> (A mallory could of course reset it still, unless you have some e-fuse or something, but anyways that's only marginally worse than simply physically destroying it.)

You can already reset CTAP2-compliant FIDO keys using a (non-PIN-authenticated) command [1], so this wouldn't add anything that isn't already there.

I think the real issue here is that users probably don't expect having to reset/initialize a Yubikey once they take possession of it. Given the horror stories of how e.g. Amazon commingles inventory, I wouldn't be surprised if fraudsters could succeed in getting paired keys back into the supply chain.

Targeted attacks to friends/family can probably also not be ruled out ("hey, i got this spare yubikey in a black friday sale, want it?"), and unfortunately something like a family member or partner trying to take over somebody's accounts isn't unheard of.

There are just too many ways for this to go wrong, and while Yubikey has, I believe, looked into this option in the past (there's a draft design doc for this idea somewhere), they probably came to the same conclusion.

[1] https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-cl...

> You can already reset CTAP2-compliant FIDO keys using a (non-PIN-authenticated) command [1], so this wouldn't add anything that isn't already there.

Ah I did not know that, thanks.

> There are just too many ways for this to go wrong, and while Yubikey has, I believe, looked into this option in the past (there's a draft design doc for this idea somewhere), they probably came to the same conclusion.

Would be interesting to see the draft. But yes of course, there are tradeoffs. Having a LED similar to on the Bio to indicate it's paired could be one way, or selling pairs in a SKU where the user actually have to initialise them (with some clear physical difference to help solve the family/friends case). But it's complicated, and I think Yubico has made the correct decision that it's simply not worth it (not that it's impossible to do in a secure way).

However, the lack of a resonable backup solution is keeping me away from Yubikey for any non-enterprise use, where a broken key would actually lock me out of an account for real.

HSMs support these kinds of scenario (high availability clusters, wrapped keys etc) but I agree. For enterprise use there's no interest or need, and for end users the feature would potentially be confusing.

I just use multiple tokens, and I knew that the infineon sle78 was an intel 80251 derivative before this report ;)

You register 4 keys on each website?

If you have a hardware key setup for anything you want sustainably operated in the future,

you register at least two keys, and when one fails or is lost, you pull the emergency backup out of a safe and register new one(s).

You also have to pull the emergency backup out of the safe when signing up for a new thing. It's highly inconvenient.

Still more convenient than getting locked out.

True, but what's even more convenient than that is to just not use hardware authenticators for anything but the most important accounts/sites, and e.g. use syncing credentials (as provided by many password managers, Google, and Apple).

The fraction of people willing to regularly schedule enroll-o-ramas at each of their accounts and each of their backup key locations is probably smaller than a percent of all potential WebAuthN users.

It becomes questionable if you’re halfway across the world from your safe.

You register multiple keys on a handful of critically important websites.

Password manager. Primary e-mail account. DNS provider.

Other than that, it's rarely supported and rarely worth the hassle when it is.

It is really annoying that more sites don't support multiple security keys, though. As far as I can tell, it's not encouraged by the FIDO Alliance and I can't think of a good technical reason for it.

I forget which financial institution I was using at the time, but they explicitly only supported one key. That is, you add a new one and the old one is expunged.

Banks are so slow with this sort of thing, and still require SMS as a fallback option.

The vast majority of sites I've used Yubikeys for have supported multiple. About the only one that I use which still doesn't to my knowledge is Paypal.

Maybe I'm out of date, then! I don't enroll new keys very often. Paypal is a great example of a service that I would like to support multiple keys, though, so it's disappointing that they still only support one.

How often do you check to see that those other/backup keys are still secure? This attack becomes easier if the attacker knows of the secondary key(s) location and because of disuse they aren't even necessary to replace.

I mean, not all at once, but (I only have 3) there's the one when I bought a new laptop in 2019 which I setup when I got that laptop and became the old one when I got a new laptop in 2021 and setup a second one. And then the third one is a backup key I made at some point and is stored offsite in case I/my house gets robbed/burgled or my place burns down in a fire.

It's inconvenient, sure, but it's more convenient than my bank accounts that are accessible online being cleaned out.

> I don't remember where I've used my YubiKey in the past.

I've yet to encounter a site that allows to enroll a FIDO device without setting up some other form of 2FA and for me it's TOTP which are kept in the app.

Yeah I stick to TOTP for the most part which means the YubiCo app has the list. I always enrol two keys though, one back up and one active.

If you're using a yubikey solely for its PGP key stuff and you have a backup of the key or have a key hierarchy then replacing a yubikey is pretty trivial.

(I know because it's my specific usecase.)

Only if the key is generated off-key

I meant to imply that with this statement:

> and you have a backup of the key

Everything about security / auth sucks in this age.

Each time I go down this path with either work or personal stuff it's just people changing passwords all the time / having to re-login all the time ... there's no happy path without a huge hassle.

> you cannot just replace a YubiKey.

How would this work?

Sounds like functionality you could implement on a blockchain...

You can implement most things on a blockchain, but only very rarely does that make any sense.