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

Interesting idea, but like @sbweeden I'm skeptical of this.

First, some surface-level thoughts:

- [`hash_to_field` (RFC 9380)](https://www.rfc-editor.org/rfc/rfc9380.html#name-hashing-to-a-finite-field) can be used to derive an EC private key with minimal distribution bias.
- I'd say the `UV` should probably be set to 0 most, or maybe all, of the time. WebAuthn keys are normally assumed to be primarily possession factors, and the UV bit represents use of also a second factor. But a password-derived key inherently is primarily a knowledge factor, so setting the UV bit would misrepresent these credentials as multi-factor credentials when they are in fact always single-factor credentials.
- Similarly, these credentials should always set `BE=1` because a password-derived credential is always trivially exportable, no matter how you store it.

On a deeper level, I'm not sure I fully understand the user interaction model here. Is the expectation that (1) the user would enter the password during each registration/authentication ceremony? Or (2) does the user import the password once (possibly in a browser settings UI) and then only authorize its use as (key derivation material for) a credential?

I agree with @sbweeden that (1) seems too dangerous because it would be fairly easy to trick many users into entering that password into a malicious site, which could then of course follow the spec to perform the key derivation and impersonate the user. Yes, dedicated browser UI would make this detectable for the most observant users, but this would likely succeed against most people as they may not know to look out for this.

(2) would be a bit less dangerous, but still open for abuse as malicious actors can still ask victims to enter their master password, or direct them on how to open their browser settings to retrieve the master password and enter it on the site. This would probably have a far lower success rate than (1), but I still think it would work in too many cases.

But whatever the UI, there's an even bigger problem with this: there isn't really any meaningful brute-force protection, and the same password would result in the same credential ID for different users. High iteration counts help, but only for nontrivial passwords and almost not at all against dictionary attacks. Many people would continue to reuse a single password everywhere, perhaps with minor variations, and many would use a very simple one that would be cracked almost immediately by any offline attack. "Salting" the KDF with a username would help a little bit to differentiate hashes between users, but again this is only really meaningful for fairly complex passwords. And once you crack an RPID-username-password combination, you can still easily try that same username-password combination on other RPIDs. Salting with any cryptographically random value would invalidate the point of deriving everything from a password alone.

So any way you twist it, the problem is that there just isn't enough entropy in most human-chosen passwords, so we end up back at still needing a password manager anyway - be it to embed more entropy in the password itself, or to store and manage auxiliary salts or keys to mix in with a low-entropy password. At that point, why wouldn't you just use a cryptographically random passkey stored in that password manager?

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2091#issuecomment-2205836860 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 11:17:13 UTC