Live data from Hacker News

A Guide to WebAuthn

webauthn.guide

91–100 of 122 posts

Re: A Guide to WebAuthn

#91
post #43
post #37

Earlier quoted context omitted.

And how do you enroll the second device? It would have to be something like; 1) Login on primary device 2) Generate a one-time code or link 3) Enter one-time code or click link on 2nd device 4) Click an “Enroll” button on the 2nd device which would generate a second enrollment saved in the account. You would have to do this for each and every service so that seems like a total non-starter. Alternatively, a way to sha…

There's an ascending signature counter that's intended to prevent cloned devices (replay attacks are prevented seperately with server generated challenge). One way around it is clone (backup key) having very high initial signature counter set, so first use invalidates original (on loss). But yeah it's a UX problem that hopefully will find a better/non-hacky solution than "register multiple keys for each site".

> But yeah it's a UX problem that hopefully will find a better/non-hacky solution than "register multiple keys for each site".

This seems like a huge blocker for adoption. I currently run into this issue with FIDO for 2fa - I store my backup key offsite, which means enrolling the second device requires me to make a special trip to retrieve the device. My current approach is to retrieve the backup token every few months and add it to all of the new services I have enrolled in, but I don't have a good system for remembering all of these services, so I inevitably forget one (despite only using the key on a few services)...

Re: A Guide to WebAuthn

#92
post #78

Why is the information that needs to be sent to the server so complicated? Specifically you need to send the rawId (raw bytes), clientDataJson (json), attestationObject (cbor) and the result of `getClientExtensionResults()` (js object). And then the attestationObject further includes an `authData` field which is itself a structure which contains another field which is CBOR encoded. Why not a single CBOR object?

Can you clarify whether you mean only the `attestationObject` should be sent to the server or that everything should be encoded as a single CBOR object and then sent to the server?

I mean why are ther multiple objects that have to be sent instead of a single cbor object. And why is some of it cbor and some of it json?

Re: A Guide to WebAuthn

#93
post #90

Earlier quoted context omitted.

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 bo…

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

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.

Re: A Guide to WebAuthn

#94

Earlier quoted context omitted.

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 (a…

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 bo…

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.

Re: A Guide to WebAuthn

#96
post #92

Earlier quoted context omitted.

Can you clarify whether you mean only the `attestationObject` should be sent to the server or that everything should be encoded as a single CBOR object and then sent to the server?

I mean why are ther multiple objects that have to be sent instead of a single cbor object. And why is some of it cbor and some of it json?

Gets worse. Some of it is ASN.1 inside CBOR too. Some of it is custom binary format containing CBOR

The answer is as far as I know:

Backwards compatibility with bad decisions made in U2F

Also; relying on base64url is odd as there are no built in functions in JavaScript to encode and decode it.

Re: A Guide to WebAuthn

#97
post #92

Earlier quoted context omitted.

I mean why are ther multiple objects that have to be sent instead of a single cbor object. And why is some of it cbor and some of it json?

Gets worse. Some of it is ASN.1 inside CBOR too. Some of it is custom binary format containing CBOR The answer is as far as I know: Backwards compatibility with bad decisions made in U2F Also; relying on base64url is odd as there are no built in functions in JavaScript to encode and decode it.

> Also; relying on base64url is odd as there are no built in functions in JavaScript to encode and decode it.

I'm probably missing something, but aren't window.atob and window.btoa just that? It's not available in Node though.

Re: A Guide to WebAuthn

#99
> After the PublicKeyCredential has been obtained, it is sent to the server for validation. The WebAuthn specification describes a 19-point procedure to validate the registration data

19 points?! I haven’t dug too deep into the details, but so far everything I’ve seen re: implementing WebAuthn seems so... over complicated? Compared to implementing, say, TOTP based 2FA, which is very straightforward.

Post reply on HN