Re: [webauthn] Proposal for password-only authentication using ES256 (#2091)

> I wonder if you did not misunderstand the credential ID construction; [...] most of the credential ID is just a randomly generated salt

Ah, thanks, I did indeed miss that part. That certainly does at least limit the scalability of a brute force attack as you'd need to crack each credential ID individually rather than all at once.

I don't think it helps all that much, though: since this salt is stored on the server (in the credential ID), it must be sent to the user before the user can derive their key from it. Since this is intended to be the only authentication step, as I understand the proposal, anyone can query the server for a user's credential IDs without needing to authenticate first - so the attacker doesn't need to compromise the server-side database to get at the credential IDs, they can just request them via the server's public API. From there, any low-entropy password will be easy to crack since the attacker has the salt. Granted, the individual salts means they can't attack _all_ users' credential IDs at once, but they don't really affect the difficulty of a targeted attack.

> The expectation would certainly be your first case.

Which is:

>(1) the user would enter the password during each registration/authentication ceremony

Ok. Like I said, I think this seems a bit too susceptible to tricking users into entering their password into a malicious webpage rather than the browser UI.

-----

<details><summary>Off-topic hash_to_field discussion</summary>
<p>
> it does not necessarily sound as though [hash_to_field] generates an ECDSA private key. [...]  (and the _u_ outputs being vectors seems to reinforce that, though I'm not sure what _m_ would be in this case)

It is a bit obtuse, but the field to hash to is a free parameter of the function. The primary objective of the RFC is the hash_to_curve function, which uses hash_to_field to hash to the coordinate field of an elliptic curve, but you can also use hash_to_field to hash to the scalar field instead:

>The hash_to_field function is also suitable for securely hashing to scalars. For example, when hashing to the scalar field for an elliptic curve (sub)group with prime order r, it suffices to instantiate hash_to_field with target field GF(r).

The _u_ vector just holds _count_ results, but you can set _count_=1. _m_ is 1 when hashing to a prime order field _F_ (because _F_ has order _q = p^m_, and _q = p_ for a prime order field). So for hashing to an EC private key you'd set _m = 1_ and _p = n_ where _n_ is the order of the curve generator (AKA base point) (i.e., the order of the prime order subgroup of the curve (which is the only (or any, depending on how you see it) subgroup of a prime order curve like P-256)).
</p>
</details> 

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


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

Received on Wednesday, 3 July 2024 16:22:11 UTC