The most common use case today is 2FA, where WebAuthn is the standard way to do something U2F defined only for 2FA.

In this scenario where it's only a second factor, yes, it relies on you possessing a Security Key, and on the bad guys not possessing it. This matches the threat model, which is typically that bad guys are not your flatmate or your mother they live in another country and will never meet you.

WebAuthn (and U2F) were specifically designed to register multiple tokens, the server-side stuff described explains how a site insists "Look I need to register a new token, not these tokens which I already registered" while also being open to whichever token you have on login, "Any of these tokens can log in, I don't mind which". So I have a token in my pocket, but if I got mugged I have a backup token at home that can substitute. Well designed sites let you nickname them during registration so you can go "I lost green hulk token but I still have Yubikey" later.

Yes, if you use the flows where both factors are handled by the FIDO token then you're "back to passwords" but with a very important difference. Very, very important:

Right now your password for news.ycombinator.com is known by the Y Combinator servers. Now, I'm sure they take good care of it, using a modern salted and pessimised hash for the purpose, but this creates many extra opportunities for vulnerabilities and a bad guy only needs to find a crack in one place.

Whereas if I have a PIN for my FIDO token the PIN lives on the FIDO token. Not on every web site I use WebAuthn with, not in a database that some poor new sysadmin accidentally uploads to the Cloud, it's not sent over the wire to some Java backend sevice that might accidentally log it, or whatever. The device can insist upon rate-limiting attempts because it's a piece of hardware, like an iPhone.

Unfortunately for the user experience, those tokens typically can’t be cloned even upon initial setup. The practical result of this is that if you intend to keep a second token as a backup, you need to remember to register the backup token individually for each service you use your primary one for. This is unlikely if you keep the backup at home, and it’s downright impractical if you kept it in e.g. a safe deposit box.

I love FIDO tokens, but I’m not confident in my ability to keep myself from getting locked out of a service I use infrequently, and I’m a fairly technical user.

> Unfortunately for the user experience, those tokens typically can’t be cloned even upon initial setup. The practical result of this is that if you intend to keep a second token as a backup, you need to remember to register the backup token individually for each service you use your primary one for. This is unlikely if you keep the backup at home, and it’s downright impractical if you kept it in e.g. a safe deposit box.

This right here is what drives me crazy about most 2fa implementations (and now apparently webauthn). I currently store 1 backup token offsite, and carry one with me. The problem is - I have no good way to access the backup device (so I can add it to my account) without having both in my possession, which destroys its abilities as a backup token.

I would love to be able to somehow have 2 fido keys use the same key, but I'm not sure how that's possible without exposing the private key externally, destroying some of the device's security properties.

You could have a single soft-U2F vault that contains all your accounts, and secure that vault with your hardware tokens. Using something similar to LUKS (http://clemens.endorphin.org/TKS1-draft.pdf), you could allow multiple tokens to decrypt the vault without exposing the master key. The downside is that there’s no way to revoke access to the vault if a copy leaves your possession.

There are tokens that support this. OnlyKey has a secure backup feature where you can have an encrypted backup file. If you lose your physical key you would just load the backup file onto a new key and all of your accounts are ready.

https://onlykey.io/

https://docs.crp.to/usersguide.html#secure-encrypted-backup-...

Allowing backups is as you mentioned a tradeoff of security vs usability. The greatest risk to your accounts is not always account compromise, it can be losing access to your own accounts. With OnlyKey you can choose to enable this feature or not. Backup requires user physical presence and restore requires the backup file and correct key/passphrase.

There are other recovery modes that don't require a second token.

One common example is a sheet of recovery codes you receive at the enrolling stage that you are prompted to print and store somewhere safely.

I've got a system where I mail these one time codes (via snail mail) to a family member as a failsafe. I only use this for 2fa, but that ensures that if I lose my key while say out of the country, I can call my family member and they can read me some codes over the phone.

It's a bit archaic in a way, but works wonderfully as an accessable and relatively secure backup strategy.

> This matches the threat model, which is typically that bad guys are not your flatmate or your mother they live in another country and will never meet you.

Yes, that's a good point. No security is foolproof. But this is an easy way to curb 99%

> "back to passwords" but with a very important difference

Also a great point. It may not totally get rid of passwords, but it does stop leaks.

What is a "pessimised hash"?

A Google search only turns up HN posts written by you.

In FIDO-speak, "platform" authenticators are your laptop or phone, using their contained secure storage, vs "roaming" authnrs like our SoloKeys. Most people assume that the former will be the main way to use WebAuthn. Consumers using keys are mostly enthusiasts/early adopters/special needs.

Mainly in a corporate setting, a separate hardware key may provide a root of trust (and audit trail if the key is modified to be trackable) , with which you can then unlock your devices in a self-service manner.

You're right that software authnrs are a bad idea.

For services that don't want the security to be pierced by such unsafe fallbacks, initial key attestation can whitelist the acceptable authenticators.

One thing that is too infrequently highlighted is that FIDO2 is decentral authentication between you and the services, unlike "login with big-corp".

Phones are one of the most likely things to break given their usage. So then you'd be locked out of the account. Requiring a smart phone or a phone number to authenticate but a high bar in certain regions of the world as well as against privacy-conscious people.

Here's a anecdote about phone and required 2FA: I was in Laos needing to pay rent when my phone broke. I was locked out of TransferWise to get my paycheck because their 2FA is behind their proprietary app so I couldn't authenticate on my laptop. Luckily I had just enough cash in my bank account. Too bad the bank only had 2 2FA options; 1) behind their proprietary app which doesn't allow rooted devices (despite root for more privacy tools on Android) or 2) SMS in which I was in another country so I didn't have access to my home SIM.

Because I needed a new phone to fix this issue, I went to buy a new one online. I couldn't pay for it because I needed a working phone to confirm a payment with my bank.

All of this could be solved by allowing TOTP (which doesn't require a phone) or FIDO2 (which I have a key).

You can make it more convenient by having a specialized USB or NFC device. The NFC handshake is really simple (tap your phone with it). Arguably more convenient than any kind of secure software-based tokens.

You can use psychical, TPM or biometric authentication, like fingerprint. The specs require one to be able to reset a login if device is lost, like with email and code or SMS.

There's usually a pin or a fingerprint reader on the usb device so that it's not usable except by the owner.