[xur17]

This is one thing I hate about these keys though - some services only support one key, and for ones that support multiple, I struggle to figure out a storage system for my backup key. I don't want to keep it with me (because then I am at risk of losing both), but if I keep it separate, I need to remember to add it to new accounts - there's no way to see a list of accounts a key has been associated with.

I'm curious how others handle this.

[Groxx]

Completely agreed. I don't have a good solution for that either, aside from "try harder". Which puts them in a fairly specific niche of reasonable use, tbh. And any site without the ability to set up multiple emails / keys / etc is not taking basic steps to allow its users to maintain access their account, so I think it's fair to rule them out simply as "bad sites" (though they're quite numerous, sadly).

For corporate purposes, they're pretty decent. If one is lost or fails or whatever, they can get you a new one, because the company can quite-strongly verify that you are you - much better than your average website. A bank or something might also be reasonable.

For general personal use... I dunno. You really don't want to be locked out permanently if you lose the key, which tends to mean they degrade to your email security, and they're just convenience tools. Which is more than nothing! Convenience that emails you when it is bypassed is better than no email when bypassed! But it's very far from the security claims that tend to go along with these keys.

Personally I'd like these keys to be a "fast login" convenience, and for email-reset to be delayed by a day or three with an easy "revoke" button. It's exceedingly rare that I truly need backup access immediately, and allowing it all the time is definitely opening the door to bulk theft of accounts.

[schrodingersket]

I keep one of my keys in a fireproof safe at home, and the other on my keychain as my daily driver. If a site allows me to enroll multiple U2F keys, I just bring the backup to work (my home office, currently) with me the next day and enroll it then. For sites that only allow a single key (looking at you, AWS), I will usually enroll the key I have on me, and then when I have both, I write the same TOTP seed to both keys (usually by scanning the QR code with each key plugged into my phone before entering the one-time code used to verify and finalize TOTP enrollment) and use that instead so that there's effectively a TOTP duplicate.

This gives me a pretty convenient list of sites I've set up the Yubikey with (at least for TOTP), since Yubico's OTP app lists all the sites I've used it for.

If a site only allows a single U2F key to be registered, I'd rather have a backup with TOTP over the better security of a single U2F key, so this arrangement works reasonably well for me.

[user3939382]

My threat model is focused on remote attacks, I consider physical access to my workstation game over. So one stays on my keys, one on my wife’s keys, and one stays plugged into my workstation.

If I’m enrolling the keys with a given service I make sure to add or remove all three at the same time so I don’t have to track which is associated with different accounts.

[XorNot]

This isn't really an adequate threat model today though, where everyone has laptops. Having a workstation stolen for most us is actually extremely likely - probably more likely then someone trying to attack our credentials.

In this case though, full-disk encryption and TPM usage is the mitigation - provided the disk goes dead when anyone short of a nation-state tries to manipulate it, you're good.

[g_p]

This is the biggest weakness of U2F unfortunately.

My approach is to keep a list (a simple text file) of what services are used for U2F, and which keys are enrolled with it.

Most services ask or require you to name the token you enrol (if they support multiple tokens) - I gave the tokens names so they're consistent.

Now I have 2 ways to check - logging into a site, you can see what keys are enrolled. And as fallback, I can use my underlying text file and see which keys I enrolled.

You just need to make a point to check the file once every so often (at least first time you are near your backup key after having edited the text file).

I've seen some interesting approaches (on modifiable tokens where keys can be exported) where they configure a backup key as a mirror of the main key, but with the counter advanced forward such that using the backup will invalidate the regular (thus alerting you to the use of the backup by an adversary, as long as the service properly validates the counter).

I can't think of an easy solution to this (it is effectively the key distribution problem) without adding complexity (like manager software for tokens, and a Shamir's secret sharing style way to export a token's root key through SSS such that it can be recovered by a quorum of keys in an emergency). That breaks various aspects of the threat model though.

Perhaps there's a less complex way to do it though? Like having up to N persistent public key slots on the token, where public keys of your other tokens can reside. When registering, the generated key is also encrypted "to" those tokens, and sent as supplementary key handles. You'd need to add a pairing relationship to validate authenticity of the key handles, but I suppose it could work.

[Arainach]

I keep one backup key in a fire safe at my residence (in case I lose my primary key somehow) and one with a trusted party in a different state (in case Mt. Rainier explodes and the entire state of Washington is lost - though at that point I have bigger concerns)

[xur17]

How do you update the copy that is with a trusted party in a different state (and how do you track which accounts are stored on each)?

[Arainach]

In non-pandemic times, I visit at least once a year and update things then.

At the end of the day, so long as I can get access to my email and at least one bank, I'm confident that I can recover everything else in time. As such, if I have some recent account that isn't covered by that key I'm not particularly concerned.