If we could go back in time and teach users that passwords are only to be entered into browser chrome, and if that used PAKE, we would be in pretty good shape.
HTTP Basic Authentication was a thing in the 90s. Couple that with TLS+PFS and you already have all the benefits of PAKE, plus the more useful benefit of having a third party verify the identify of the web server the first time you visit.
The major reason HTTP Auth failed, despite the primitive crypto, is the bad client side UX.
> PAKE doesn't share the password with thr server.
The server has a password derivative stored. An SRP verifier for instance is computed from the password hash, so if the server is compromised the hacker can immediate impersonate the server or the password can be brute-forced offline.
I believe OPAQUE is the same, just with stronger (slower) password hash functions in the mix.
A server may store the password hashed, but in a password-over-TLS flow the password is received by the server in plaintext. It is only encrypted on the wire (& the network stack).
Look at all the places in a standard authentication flow where the plaintext password is exposed:
- Any TLS-stripping middleboxes on the client's network. (My personal security nightmare is that someone finds a vulnerability in one of those, and hacks them to scrape anything that looks like a password.) BTW, remember when Kazakhstan did this to their entire country?
- Any TLS-terminating load balancer/front-end-server/etc at the server side of the network.
- Potentially between the front-end server and a backend that does the actual authentication, depending on how traffic is passed there.
- Finally, the server that's doing the authentication -- the password will at the very least be exposed in memory there, so anyone who can read its memory (or modify the server code to leak the passwords) can collect passwords in plaintext.
I agree that with the likes of industrial scale MITM (Cloudflare) in the pipe it's not good... but remember Cloudflare also has access to your session tokens, not just your password, so a PAKE might not help without seriously reworking how we do sessions also.
I'm less concerned about corporate level MITM since in those scenarios the MITM already owns the clients. Regardless of protocol, it's a lost cause there.
Of course if you have the server config and database you could impersonate it. However, phishing would be nearly pointless as most phished sites aren't/hadn't been compromised. (Well, pointless in the universe where entering a password into form elements and not the browser chrome isn't common and taught as a faux pas to users.)
Also, as it is you can brute force hashes offline as well. Yes, the original specification has become weak over time, but so have 3des and md5. SRP never was heavily used and as such new versions arent common; it's not inherently a problem with the concept of password-based mutual authentication.
If the server is compromised, of course the attacker can impersonate the server. With an _augmented_ PAKE (which OPAQUE is), the attacker cannot impersonate the client without a brute forcing step.
