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

Ah, I see now. I think I assumed the MAC would involve the password, but indeed it does not. Here's how I understand the proposal in pseudocode:

```
password = input()
salt = random()
n = config.n

cred_id_tail = "pbkdf2-sha256" | 0x00 | encode(n, salt)
cred_id = LEFT(8, SHA256("pwkey" | cred_id_tail)) | cred_id_tail

prk = PBKDF2(SHA-256, SHA-256(RPID) | password, salt, 1 << n, 32)
pri_key = hash_to_field(prk, ...)
pub_key = pri_key * P256.G
```

So ok, the credential ID alone isn't enough to mount an offline brute-force attack since there's nothing to verify attempts against. An online brute-force attack is still possible, but then of course the target server can deploy rate-limiting restrictions or the like to make the attack far less scalable.

> You would be able to brute-force a `(credential-ID, public-key)` pair, but that would at least require the server-side data getting leaked.

Yeah. You could also brute-force a `(credential-ID, signature)` pair, as that gives the attacker something to test a public key guess against. That would require the attacker to passively eavesdrop on a registration or login ceremony. As far as I can tell the difficulty of both of those attacks is equivalent to breaching a password database or passively eavesdropping on a password entry. So yeah, this proposed approach seems to not introduce any new vulnerabilities compared to traditional password authentication.

On that note, though: I'm not convinced we want to lower the bar for WebAuthn to just "not worse than a password". At least in my opinion, WebAuthn is supposed to be _better_ than passwords, not just equivalent, and I'm not convinced this approach is enough of an improvement over traditional password authentication.

You wrote in the initial comment that:

> * Password authentication would stand to benefit a lot from the strong anti-phishing protections that WebAuthn offers.

But I question if it actually would. The inescapable problem with passwords is that they _can_ be entered into a malicious input field, whereas a WebAuthn credential cannot. The strength of WebAuthn is not that it is _possible_ to use it securely, but that it is _very difficult_ to use it insecurely. Any password-based system inherently struggles to achieve the latter since a password can always be entered anywhere.

I applaud your effort to come up with a fairly good design within the design restrictions, but I don't think WebAuthn is the right home for it. But perhaps some [PAKE](https://datatracker.ietf.org/doc/draft-irtf-cfrg-opaque/)-based approach could be a candidate for a new credential type in the [Credential Management](https://w3c.github.io/webappsec-credential-management/) API (which WebAuthn itself is an extension of)?

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


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

Received on Thursday, 4 July 2024 12:48:02 UTC