Re: [webauthn] Can we document protections (if any) around userHandle (with user-verification)? (#2266)

> You don't say what you plan to do with the sensitive user handle or what information it apparently will contain

I chose not to clutter the thread with the specifics, as I didn't want to invite bikeshedding over whether people think what I'm doing with that field is valid or a good idea or moral or whatever. I was focused on trying to understand what, if any, protections the field has.

That said, what I'm storing in that field is the locally generated seed for an elliptic curve (Ed25519) keypair, used for local encryption/decryption of data at rest, and for limited P2P encrypted transmissions. Again, this is all for entirely-zero-server local-first applications.

> Consequently, you must not rely on a "secret" user handle; doing so is in violation of WebAuthn.

I don't have any idea if the seed of an encryption key counts as PII or not, but quite frankly I don't care. I'm not using a FIDO server for local-first (again, zero-server) applications, so it's quite clear that I'm piggybacking on webauthn but using it in a totally different way than it's intended or designed. But it's not relevant to me what the mechanism is intended to do, it's relevant to me what it actually does or does not do.

I'm sure readers here will have plenty of opinions about whether this is a good or terrible idea, but... I'm doing it nonetheless, I have written a library to let others do it, I'm advocating it in conference and meetup talks, etc. 

> "guarantees"

That was quite an extensive lecture on my inappropriate or misdirected usage of that word in my questions. I regret asking it with that word.

Put simply, I've done a bunch of testing on the types of devices/OSes (and thus authenticators) that I am *expecting* to be used in these local-first application scenarios, and thus far, my testing strongly says that "userHandle is gated by UV". I knew the spec said "no, the userHandle is not *necessarily* gated by UV", but then the spec goes on for a whole paragraph about how they *should*:

> If an authenticator chooses to do so, it SHOULD NOT expose personally identifying information unless successful user verification has been performed. If the authenticator supports user verification with more than one concurrently enrolled user, the authenticator SHOULD NOT expose personally identifying information of users other than the currently verified user. Consequently, an authenticator that is not capable of user verification SHOULD NOT store personally identifying information.

I don't know why there's so much couching/waffling of "is it protected or not" here, but it was *the* source of my confusion (in light of my own testing), and so I came to the *source* to ask basically, "Hey, what's this mean... is it protected or not".

TBH, I don't have any more clarity on my fundamental question than when I started. Except maybe "Nobody can say one way or th other, because the authenticators out there could do whatever they want".

OK, fine. So my conclusion is, some (maybe most) folks using my library/approach will likely be protected, but some out there might not have as much protection, but there's precisely zero I can do to understand or predict or control that, so... shrugs. I guess I'll just tell folks, "when it comes to security, YMMV."

> PRF, HMAC

Yeah, of course, these are *obviously* the far more appropriate mechanism -- as is, FWIW, the `enforceCredentialProtectionPolicy` feature.

The problem is, they are only theoretical. In precisely zero devices/OS's I've tested do any of them work.

So, I decided it was better to push forward with a less-than-perfect "hack" or storing the seed in the userHandle, and trying my best to do due dilligence to understand the security implications thereof, on behalf of anyone who uses my libraries, and to do whatever I can (if anything) to offer as much protection as there could be (if any).

> your posts are extremely lengthy

I'm sorry I annoyed folks here. If you look up-thread, I started out relatively much shorter in my earliest posts in the thread, but I was increasingly baffled by the answers I was getting, and it seemed clear that it was because there was no "reading between the lines" or "understanding of context" automatically happening. So I got more verbose and detailed as the thread went on, to try to more precisely communicate what my questions and confusions were.

I guess that was a mistake. Sorry.

In any case, I don't think there's anything left to discuss here, so I'll go ahead and finish. Thank you again for your time, it's appreciated.

-- 
GitHub Notification of comment by getify
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2266#issuecomment-2723692495 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 14 March 2025 06:00:26 UTC