Item — HN Reader

Ideally there would be a way to create "tickets" or something from an authenticator in advance and then use them for registration without physical access to the device. Then I could have 100 tickets from my backup on my master, keep the physical backup in a secure offsite location, and enroll new services using master + backup-tickets. When I run out of tickets, generate 100 more.

Being able to export/back up/restore master secrets would be nice too.

3 comments

https://www.yubico.com/blog/yubico-proposes-webauthn-protoco... Is basically that, but with infinite tickets :)

This sounds suspiciously like PGP subkeys. Having not read into how FIDO works, I'm going to now assume it works by supplying a "public key" to a third party, and the third party authenticates by having you encrypt a nonce with a private key. How far off am I?

FIDO involves creating a new public/private key pair for each website, to prevent cross website tracking. The keys are derived from a secret stored on the device, so the device doesn't need to store anything but that secret, which enables it to be used with a limitless number of websites.

Edit: there seems to have been a paper that studied the very question of "can you create keys asynchronously so that you can later use them with a backup key": https://eprint.iacr.org/2020/1004.pdf https://www.youtube.com/watch?v=urJ2DhpLAEk

I need to read the paper however on how feasible an implementation of this is, and how much buy-in it needs from website and browser vendors.

Cryptographically speaking it's signing a challenge, not encrypting a value (which would be a public key operation), but generally speaking yes, that's the idea of it!

One of the things FIDO adds beyond a protocol for "plain" hardware-generated and stored keys is the idea of attestation, i.e. authenticators being able to express statements like "keys can never leave this authenticator" or "this key requires PIN or fingerprint verification" – all assuming you do trust the manufacturer.

However, you should not require attestation for public services. If you let Jim sign up with his dog's name as a password, but then refuse to let Sarah sign in because her FIDO device wouldn't provide "attestation" you're crazy.

Attestation probably isn't the correct choice for almost anybody, but the cases where it could at least make sense are if you're an employer checking employee authenticators, if you gave everybody a Yubico Fantastic XXV authenticator, you might decide it makes sense to verify the credentials enrolled are from Yubico Fantastic XXV authenticators. But still probably not. On the whole, everywhere I see UIs for managing attestation it makes me a little bit sad, because it's an attractive nuisance. Azure AD for example does this.

It might be that if someone has a hardware key which makes a sufficient attestation, you disable some OTHER supplemental authentication mechanism; like, if it says it requires a biometric, then you could allow auto-login in a context where you'd otherwise also require a pin or other second factor.

You can't say "Does it require a biometric?". The attestation is proof this device was issued by this manufacturer, so you're going to be whitelisting manufacturers and maybe specific product lines. Somebody technical needs to understand how to determine matches, and then somebody with authority needs to decide which ones are acceptable (maybe they're going to buy and test each model?), only if you're actively doing this is it even viable.

Now, I want you to imagine if corporate has to approve motor vehicles for the HQ's 600 vehicle car park. Of course the CEO's BMW M5 daily driver is approved, and for the first week maybe the random cars owned by people who regularly use that car park get whitelisted pretty easily. By the next month though, one of two things, either you're told just buy the same exact model of car as the CEO to "save trouble" or everybody just tells you to use a different car park nearby, and the HQ real carpark sits mostly empty because approval is a hassle.

The right answer, you can see, is to just not have a rule whitelisting cars at all. It's a bad rule.

If all you want to ask for is "Use a second factor" then you can do that, there's a flag in WebAuthn, and the resulting signatures have the UV bit flag set (all WebAuthn signatures have UP set, but Presence of users is distinct from Verification of users). Because it's a signed flag, even though it's a single bit, you can rely upon it unless you don't trust the device you enrolled. But, again, why? What is your threat model where your users do deliberately enrol untrustworthy devices but presumably never just helpfully enrol a device for a crook ?

Sure, don't require attestation for services where 2FA is completely optional.

But for sensitive systems/services, why not make use of the advanced capabilities that hardware authenticators offer? I'm using one in a corporate environment, and in my view it makes a lot of sense.

I'd also not be upset if my bank would let me bypass the mandatory "account restricted, call customer support" dance every time I initiate a transfer over $10 between my own accounts using only a "trusted" authenticator brand... And banks typically care a lot about security properties like "this authenticator does not allow extracting private keys".

Existing devices with BIP39 random seed backup support have you covered here with far less complexity.