Why PAKE or Zero-knowledge password proof didn't replace sending a password via HTTPS

Question

Technologies like Zero-knowledge password proof and PAKE seems to be pretty mature but almost all modern web-sites still send passwords over HTTPS to check authentication. At first glance, this protocols look like a magic pill, but still not adopted, I'm wondering why.

Answer 1

The simple, and mostly correct, answer is that there's no good reason to do so. You're not adding any significant security this way; unless your server or client is compromised, the likelihood of TLS-transmitted passwords being intercepted is very low, but if the client is compromised then the password can be grabbed directly and if the server is compromised then the attacker has little need for the password and (in the case of web sites) could serve a modified page that collects them directly anyhow. It's true that this answer isn't fully correct due to risks such as incorrect logging or collecting passwords for reuse on non-web apps or so on, but the honest truth is that most of those aren't a concern worth putting great effort into defeating. In security engineering terms, the threats that ZKPP mitigates but that TLS and other standard practices don't mitigate aren't a big deal, so the threat model says ZKPP isn't important. It's also worth noting that ZKPPs don't actually fully mitigate risks like incorrect logging; if the logs are generated client-side (as many are, for modern apps), they still might contain the password.

Another reason, as your PAKE link points out, is that there aren't a lot of implementations. TLS is easy to use; every non-trivial programming language either supports it in the standard library or has well-supported bindings to a library implementation (usually several). In the worst case (or when scripting), you can use pipes or other IPC to common TLS-enabled tools like curl or openssl. Then the server needs to hash the value, but the same applies there; lots of standard implementations, and third-party library implementations in or binding to ~every language for newer constructions, and they're generally easy to find docs for and to use. By comparison, there aren't a lot of implementations of PAKE (or any ZKPPs), and most of those that exist are going to require additional developer effort to locate implementations and documentation for, and then even more effort to use, compared to the familiar and easy option of TLS (which you're almost certainly using anyhow, making it free) plus password hashing. In today's fast-paced development world, that's a meaningful cost that is only justified if it mitigates a meaningful threat.

Finally, there's the issue of account registration and password rotation. This generally only applies to "balanced PAKE" and similar implementations, where both sides need to know the password, but some other ZKPPs have the problem too: how do you tell the server what password it should expect from the user (or the user what password they should send the server), without transmitting that password (in some plaintext or reversibly-encrypted form) over the network? Obviously we shouldn't let the perfect be the enemy of the good, here; reducing times that passwords are directly transmitted to account establishment and password reset/rotation is better than doing so on every login. But it still pays the price of adding complexity, and for less benefit than might be expected.

---

With all that said, the ability of OPAQUE to offload expensive password hashing to the client (without making any server-held data become password-equivalent) is nice. You can of course do this with simple password[-hash]-over-TLS too, but then you still have to hash again on the server or else the server's DB ends up holding password-equivalent values. In my opinion, that - more than anything else here - is a compelling advantage for a ZKPP. Maybe some day there will be common libraries that make it as easy to use OPAQUE or a successor as password-hashing libraries make it easy to use bcrypt or argon2 with a password sent over TLS.

Answer 2

There are a number of issues, which I will elaborate on below. Some are far more important than others. I should also note that I played a role in 1Password's deployment of SRP in late 2015.

1. Simple password-based authentication is easy to implement. Nothing new needs to be done, and nothing special needs to be deployed client side

2. Patent uncertainty. PAKEs became more popular after some US patents expired.

3. TLS improved and became much more wide spread, and so most (but not all) of the problems solved by PAKEs were already solved by TLS.

It might be easiest to illustrate these points by talking about what we went through with 1Password in starting to use a PAKE (SRP) seven years ago.

TLS vs a PAKE

We, 1Password, had security requirements of for authentication that TLS didn't provide. But these security requirements may not be shared by everyone.

First of all, we never wanted to receive a user password. In traditional password authentication (over TLS) the service receives the password, hashes it, and compares the hash to what is stored. Even if the service throws aware the unwashed password immediately it still receives it. On a typical service, that isn't so bad because the service would have full access to, well, itself anyway. But in our case, the user's password could be used (in conjunction with other things) to decrypt their data, which is something that we never wanted the power to do. So for us, where the user secret used for authentication is (related to) the user secret for decrypting data, Zero-knowledge was much more important.

For typical services however, the need for zero-knowledge is reduced. Having the unhashed password server side doesn't add to the power of that server. A malicious server could make use of knowing a user's password in trying to compromise other services due to password reuse, but it does not give itself increased power over its own service.

We also wanted stronger mutual authentication than what TLS provides. With a PAKE the server also proves that it knows a user specific secret to the client. TLS provides some authentication of the server's domain name to the client, and even that is not as reliable as we would like.

Finally, we wanted to have a session key for encrypting and authenticating messages in a way that tied that key to the authentication process. Messages between client and server are cryptographically bound by to the authentication proofs from the PAKE.

So for us, we had needs that TLS doesn't provide. Sure, this would be "nice to have" for more typical services, but may not be worth the effort.

Implementation

At the time, we had to write PAKE client code into five different code bases in five different languages. Even if today there are better libraries that one can link into different clients, it is still going to be an issue. And, of course, it means being the ones who deploy the clients. Not every service is in a position where they write all of the clients.

While things have gotten easier over the past seven years, it is not a matter of flipping a switch to use a PAKE. But setting up a traditional username/password system is easy, familiar, and doesn't require adding and maintaining complicated code into clients.

Patents

There were a number of US patents that could be interpreted as applies to (many) PAKEs. It doesn't really matter if you and ultimately courts judge that your use of them was non-infringing. Patent trolls could still make your life miserable and extort money from you if they thought that they had the barest hint of a sliver of a case. Software patents are toxic.

A patent that could be seen as covering SRP expired in May 2015 despite the fact that SRP was designed to avoid problems with patents. Another important patent expired in March 2017.

While there are plenty of places in the world where these patents didn't apply, nobody wanted to build a system that would require a different authentication scheme for clients used within the United States.

A consequence of this is that for decades after PAKEs were initially invented, there was little deployment of them. In that time, TLS addressed some of the most relevant problems that PAKEs solve.

The future of PAKEs

I love PAKEs, and I wish they had come into general use earlier. But I suspect that variants of WebAuthn/passkey will make PAKEs less relevant for broad use. WebAuthn/passkey offer many of the same security properties of PAKEs in addition to other ones. There will always be places where passkeys aren't appropriate, and PAKEs will continue to have a role; but I don't foresee PAKEs becoming the successor to most traditional username/password authentication as passkeys will cover that. PAKEs and traditional authentication will always have their role, but passkeys will be the dominant technology.