Comment by tialaramex | Hacker News Reader

Comment by tialaramex | Hacker News Reader

Parent Full thread

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 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.

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.

> 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.

Reply on news.ycombinator.com