> This is correct, and I'm not sure there are good ways to prevent this or equivalent scenarios from occurring. I believe there isn’t indeed, sorry this part c

> This is correct, and I'm not sure there are good ways to prevent this or equivalent scenarios from occurring. I believe there isn’t indeed, sorry this part came out as a criticism. I actually have deployed a PAKE at work for a corporate CRUD app once, and the entire security hinged on login/password. Clients authenticate to the server with the password, server authenticates to the clients with its database entry. Sure the password could be brute forced if the databased leaked, and sure anyone could impersonate the server with a database entry, but this reduced security allowed simpler and more convenient administration: no need to bother with a PKI, just take good care of the password database and reset everyone’s passwords when we suspect a leak. (Now if this was for the wider internet I would have added a PKI layer on top to prevent server impersonation.) > The reason for having this mechanism […] Yeah, PAKE is real nice. Ideally every password based login system would use augmented PAKE under the hood. Not only does it protect the passwords better, the protocol itself doesn’t need to happen in a secure channel (this can help reduce round trips), and the bulk of the computation (slow password hashing) happens on the client side. This reduces both network load and server load, what’s not to like?