Even with this problem, using the keys for U2F is safer than SMS two factor auth. Possibly also safer than authentication app on phone, which could be compromised in various ways.
To be clear, "this problem" requires the attacker to have sophisticated equipment with physical access to your key for a significant amount of time. So yes still by far the most secure way, right below a non-clonable key.
The attack recovers an ECDSA private key for one account. So e.g. maybe your Google account. But this key does not exist when you receive the Titan in its packaging, it's created (randomly) when you enroll the key for your Google account.
These devices create entirely random ECDSA private keys for every single enrollment, and this attack recovers one key, using a real challenge from the relying party for that key. If they want your GitHub, or Facebook or your US government account, those have separate keys which need a separate attack.
It's been a while since I've read the U2F spec and my info may be a major version out of date but I understand that the enrollment-specific key was encrypted to the long term device key then returned to the service for storage.
The attack to mount would be against the long-term device-specific key, no?
You are correct about how this works. I think the "Side Journey To Titan" paper makes it obvious the authors also understand how it works.
So if you can magically summon working attacks, you would choose the symmetric AES key yes.
One conclusion you could draw from this paper is the authors are idiots and didn't realise they should attack that key or else didn't have the relevant expertise to do so.
Another, I suspect far more likely conclusion is that protecting AES keys in dedicated security hardware is a problem lots of people already put effort into and these researchers wisely concluded they wouldn't get any traction there because this is a standard component.
Does the Titan key not allow you to regenerate the key? That normally should be the first step after getting a hardware key. Yubikey definitely allows a full reset.
Compared to TOTP, U2F uses asymmetric cryptography to avoid using a shared secret design, which strengthens authentication against server-side attacks. Hardware U2F also sequesters the client secret in a dedicated single-purpose device, which even given the vulnerability described here still has a tiny fraction of the attack surface of a TOTP app and its general purpose host device.
At risk of telling you something you already know: you can use the TOTP mode on the Yubikey, if you’re looking to use it for AWS secrets despite AWS’s lack of support for U2F for CLI workflows.
That at least keeps more of your MFA key material on the hardware token and off of your phone / other shared devices.
The easiest way to do that is via the ykman CLI or Yubico Authenticator application (TOTP secrets stored on the key via either method go to the same place, so you can use both interfaces to access the same codes):
I've been meaning to buy a Yubikey. What is the best practice for using a security key? Is there a mechanism for backing my keys up somewhere safe so that a loss of key doesn't mean a loss of my accounts?
The main idea with a security token is that you can not get the keys out of them.[ß]
So for a truly secure and reliable setup, get three. Enroll them all as parallel 2FA tokens. Keep one with you, one in a relatively easily accessible but non-obvious place, and one in a safe or bank deposit box. That way when the one you have with you breaks or you lose it, promote the secondary to your primary and order a new one to replace the promoted one.
The third is your emergency backup, for when both normally needed keys are destroyed or lost.
Now of course, this only works when the accounts you want to secure allow to enroll more than one FIDO2 token. Which is, sadly, not the most common setup still. For instance AWS only allows to enroll one 2FA token per account.
ß: Some functionality modes allow to extract private keys by design.
I keep one always plugged into my computer (like a Nano model), and one on my keychain. You don't usually need more than that as there are ideally other ways to recover your account (printed recovery keys etc).
If your laptop gets stolen with key inserted, and you didn't have time to invalidate the key, one still has to access your local account, and find out saved login information in order to leverage that key, and that's until you notice that your computer's stolen and invalidated your key everywhere. Otherwise, it's just another random key for the thief.
I don't find that part of my threat model, and I've got my laptop stolen before with key plugged in.
The SSH setup with a Nano and a laptop is pretty neat, in fact. Once you get it going. For a desktop it wouldn't work as smoothly thanks to the touch-for-every-auth requirement.
Even with the well-known document (by HN regular StavrosK) at hand, you can have a confusing experience getting the resident keys going at first. So I put together something to hopefully help people out: https://bostik.iki.fi/aivoituksia/projects/yubikey-ssh.html
FWIW, when I was working on the draft version, searching for the special error code brought up only three pages in Google, and only one of them was actually helpful. At least in my filter bubble.
PS. I am aware of Filippo's yubikey-agent, which AFAIU uses PIV instead of FIDO2. Looking into that will be for the future.
Is it considered a no-no to use it with a password manager for other accounts that I consider less critical? I was thinking that for most accounts, I would use the password manager, but use 2FA for the password manager. My primary email account that everything links to, would just be 2FA.
Meaning, I would only really have to remember two strong passwords. The rest would be strong passwords, but without 2FA, and easily changeable without forcing myself to remember yet-another password and which account it belongs to.
Buy 2. Put one in offsite location (e.g. your notary). I don't have a notary; I got one always in my pocket, and the other one at home in a safe (pickable though). YMMV.
You may want to look into AWS Single Sign-On. In may not be available in the region you're mostly using but that's not necessarily an issue [0].
The service itself is free but requires an identity provider. If you already have a compatible one, you can use it at no additional cost. Otherwise, you'll have to pay for the IdP.
This setup allows you to offload MFA handling to your main IdP with the added bonus of using the same method of authentication, possibly integrated into your OS (for example if using Windows Hello / AzureAD).
At work, we use Azure AD as the IdP for AWS SSO and it works fairly well, aside from Azure's crappy (inexistent) support of security keys outside of Windows.
There is one gotcha with an easy workaround: the SDKs don't usually support the login part of the SSO flow, and sometimes don't support it at all (terraform comes to mind). To work around this, I'm aware of two tools you can use:
* aws-vault [1], which I personally use and works great for setting the required environment variables, no need to actually have it handle any sort of key
* aws-sso-util [2], which I've seen recommended but never tried
---
[0] It may be an issue if you need to use the managed ActiveDirectory service, which needs to be in the same region
AWS' support for security keys is crap in general. For example, you can only have a single key per account so it's impossible to have a backup key in case you lose your primary key.
AWS is crap in this regard, because you can only have a single 2FA device registered for your root account.
That means if you lose that 2FA device, you're hosed. Unless you can convince support to turn off your account's 2FA which one would hope they wouldn't do under any circumstances.
Instead, you should use TOTP with a mobile app. That way you can make a backup by enrolling several phones with the same QR code - or printing out the QR code and storing it somewhere safe.
Alternatively don't use u2f on your root account, just on a standard user. And never touch the root account for anything other than provisioning users.
Or use two security keys, one on your root user and another for your own personal IAM user, but you're right, don't use your root user for everyday tasks.
