It doesn't really solve any problems in the modern web stack, where passwords authenticators are stored in better formats than SRP's and transmitted over TLS to begin with.

Could you elaborate on that? I'm assuming by "password authenticators" you mean the different hashing algorithms one could employ to securely store passwords.

With SRP, you're protected from replay attacks, and from eavesdropping. You also don't need to trust the server's certificate, which can be a problem with obscure IoT devices.

For icing on the cake, you can do client-side hashing of the password before running it through the protocol so that even if the attacker took over the server, they would have just as difficult of a time running an offline dictionary attack.

The downside for that last part is how underdeveloped the WebCrypto API currently is. You wouldn't be able to use bcrypt or the like without needing a third-party library.

TLS provides much the same protection from eavesdropping, and is practically the universal standard today. Modern password hashes are superior to the augmented authenticator form SRP stores. And you cannot simply "replay" a TLS session. In the modern web stack, the only thing SRP actually accomplishes is the authentication of a TLS connection with a password rather than certificates, which is a fringe use case.

PAKEs are interesting in custom protocols; for a recent and valuable example, see Magic Wormhole. But the reason you don't see them everywhere is that they're just not that useful in web applications.

You treat TLS like a silver bullet. Yes, it's common, but so are TLS intercepting CDNs like Cloudflare which can do a passive attack to find out user passwords. Also, if the password never even enters your network, you are safe from any misplaced debug setting that accidentially logs your passwords (happened to facebook).

The only disadvantage from SRP is that you can't do server side stretching which means you are limited by device concerns like battery power for your stretching parameters.

From what I've gathered from the discussions & links on here:

Our current solution for password authentication is perfectly fine, unless you distrust your CA's.

SRP itself is a bit of a mess, and has gone through a lot of iterations to fix its faults. OPAQUE is probably your best bet. But implementing the protocol seems like overkill for password auth, and is easy to implement improperly.

Such PAKE's will likely prove to have other good use-cases, however, like magic-wormhole.

This sounds about right? Nobody really "trusts" CAs, but the whole WebPKI system that surrounds it is a lot more intricate than most people understand, and we've reached a sort of trust detente with it. The pressure to replace it root-and-branch is mostly gone now, and whatever replaces it, it won't be PAKEs.

I like PAKEs just fine and in particular really like Magic Wormhole.

It isn't used everywhere because it's much too new, nothing like SRP existed when password elements were added to HTML let alone back when the authentication mechanism was added to HTTP itself.

Also none of Tim's toy hypermedia system is built from state of the art components. HTTPS is a retrofit, graphics are an afterthought, the reason Tim succeeded is that since this was not his academic field he felt confident to do a half-arsed job whereas people who'd been doing this for years wanted to actually solve the hard problems first.

Why we didn't suddenly wake up in say 2000 and switch to SRP? Because for every crap site they already had a crap password system, no obvious incentive to get a good one. And as another poster points out this particular PAKE is/was patented which always stifles usage.

Some problems are listed at https://blog.cryptographyengineering.com/2018/10/19/lets-tal...