Add support for SRP (or some other PAKE) in WebAuthn

[dolda2000]

WebAuthn currently standardizes support for RSA and EC public/private keypairs. It can perhaps be argued that it would be nice if support for the Secure Remote Password protocol, and/or some other PAKE like OPAQUE, were added as a standard algorithm.

Unless I misunderstand something, a good PAKE (like OPAQUE) with a randomly generated password is no less secure than a RSA or EC key, but supporting a PAKE algorithm would also extend the usefulness of WebAuthn to using passwords in a much more secure manner.

It could perhaps be argued that websites can implement PAKE algorithms on their own without needing it integrated into WebAuthn, but having it in WebAuthn would be nice, partly in that it would encourage adoption on more websites, and partly because it could allow a user to choose between passwords and other WebAuthn mechanisms through the same browser-based mechanism, without websites needing multiple authentication options in addition to the WebAuthn UI also allowing multiple suboptions.

I'm not entirely sure if the values that are exchanged as part of the various PAKE protocols fit neatly into WebAuthn's model of credential ID, nonce and signature, but I reckon in the worst case, they could be encoded as structured IDs and signatures, no?

[Firstyear]

The security issues around passwords are not resolved by things like PAKE. You are assuming the threat is MITM or theft of the stored pw hashes.

The real threat is phishing, social engineering, and bruteforce. This suggestion does nothing to address any of the real threats against passwords.

I think there is no interest to add or support PAKE in Webauthn since this would be a huge departure from the current definition of the specification.

[dolda2000]

Perhaps you are right.

My main idea was that it would be quite nice for me, as a moderately security-conscious user, to be able to know for sure that, when I sign up for a service with PAKE over WebAuthn, the server never sees my password in plaintext, has no opportunity to store it in an insecurely hashed way or leak it in some other way.

Also, to be able to use a PAKE-based password as last resort in the still not too uncommon situation where I don't have a FIDO authenticator available to me, in which case I would also think that such a scheme would make phishing more difficult, since the password entry would need to happen via the browser's UI, which shouldn't be possible to impersonate by a malicious site.

[emlun]

such a scheme would make phishing more difficult, since the password entry would need to happen via the browser's UI, which shouldn't be possible to impersonate by a malicious site.

This would only be true on the honest site, though. There would be nothing stopping an imposter site from showing a plain password entry form on the page instead of invoking the WebAuthn API. This would likely be enough to trick most people, since the difference is rather subtle - especially if the website tries hard to mimic the browser UI the victim is used to. Then the imposter can perform the client side of the OPAQUE protocol, for example, to authenticate as the victim to the real server.