If you're asking that question you don't understand the purpose of SRP or ZKPP. If you're giving a password you use elsewhere to a website, you're trusting them with your private data, and you shouldn't. As developers it's our jobs to prevent users from making this mistake if we can.

When using SRP or another ZKPP scheme, trust doesn't enter the equation. You aren't giving the server your password, you're giving them a piece of data which is verifiably difficult to reverse to obtain your password, so you don't need to trust them to store it properly.

> What's especially ironic about your comment is that password-authenticated key exchanges still require servers to store authenticators which can be attacked offline.

This isn't ironic: this is exactly what I would expect from kerkelsager's comment. Again you're just showing your ignorance. Yes, you can attack an authenticator. The point of ZKPP is that it allows the client to verify that such an attack is computationally difficult. If you've given the server your password in plain text (or reversibly encrypted form), you can no longer verify that obtaining the password from the authenticator is computationally difficult. For all you know, the server stores your password in plain text. This isn't a theoretical problem: there are numerous examples of this happening.

> PAKEs actually make the problem we're talking about harder, not easier, because the authenticator format has to be compatible with the protocol.

If you're objecting to implementing things correctly because it's hard, software might not be the right career for you.

Think from the perspective of a non-technical user. You're lazy, so you want to use a short password that's easy to remember, and you want to use it on every website.

Now think from the perspective of a software engineer. Your non-technical users will use short passwords that are easy to remember and therefore easy to break. And they will use that password on every website. So no matter how you store your user's passwords, some idiot server administrator somewhere will store those same passwords in plain text, and they'll get hacked, and the hackers will have access to your user's passwords.

So the problem isn't "how do I store passwords securely", it's "how do I prevent my users from giving their passwords to an idiot server administrator who won't store them securely".

And as a technical user, I also have this problem, which is "how do I know if my server administrator is an idiot and is storing my passwords in plain text?" The solution to this is to use different high-entropy passwords on different sites, but this is tedious.

If ZKPP (zero-knowledge password proof) is widely adopted and supported in browsers, it solves both the server administrator's problem and the technical user's problem:

1. It stops idiot server administrators from storing passwords in plain text. The "zero knowledge" part of ZKPP means that users never give server administrators their password or any knowledge about their password, so administrators can't store the password stupidly.

2. As a technical user, I can now use the same password on multiple sites, provided a) my password is significantly entropic and b) all those sites use a ZKPP scheme. Since I never give the password to any site, I don't have to worry that one of them will store my password stupidly. My browser does the job of providing different authenticators to different sites, so breaking one authenticator doesn't break all of them.

3. A non-technical user with a low-entropy password on multiple still runs the risk that their password will be broken one one site, breaking it for all sites. However, the non-technical user is still better off because a) their password is at least properly hashed on all sites, rather than being stored in plain text, which will make an attack more costly, and b) caching password hashes amortizes the performance hit of password hashing, so we can afford to use more secure hashes, which again makes an attack more costly.

NOTE: I don't know the details of SRP well enough to know whether all these benefits apply. I do know that SRP claims to provide a ZKPP, so I'll tentatively lump it in with ZKPPs, but I haven't actually verified the algorithm personally so I can't speak to its security.

Go through the exercise of cracking an SRP authenticator to see the problem with this logic.

Weirdly, despite saying upthread that I must not know how SRP works to say what I'd said, you now say that you're not familiar with SRP. If it helps, substitute your favorite password protocol instead of SRP. I believe the problem will be the same.

If not: happy to learn something new.

There are mathematical proofs of SRP's security. Yes, there are some issues with some implementations of SRP, but those are problems with implementations, not with SRP. Frankly, this is just one of those arguments at this point where it's clear you don't actually understand the fundamentals of security and you're too committed to your argument and too proud to admit you don't know. Since you can't actually make an argument, you're just presenting me with difficult/impossible tasks and claiming that if I did them it would prove your point, knowing full well that I won't do them. If you actually were knowledgeable on this topic, you could explain it: I have explained everything I said so far.

> Weirdly, despite saying upthread that I must not know how SRP works to say what I'd said, you now say that you're not familiar with SRP.

I don't know all the exact implementation details of SRP, but I do understand the general architecture. The problem is that the devil in security is often in the details. I know enough to know the limitations of my knowledge. The important thing for the sake of what I'm saying is that I know what problem SRP is trying to solve.

> If not: happy to learn something new.

The only thing I'm going to try to teach you at this point is this: if you're going to even bother forming an opinion on something technical, you had better be damn sure you're right. Because if you're wrong, it's human nature to react negatively when someone tells you you're wrong, so you'll try to argue about something you're wrong about, and the result is: you'll never learn, and you'll probably impress some people who know even less than you, but you'll embarrass yourself in front of anyone who actually knows what they're talking about, and you'll limit your progress as an expert in your field. You'll never get smarter until you stop trying to prove how smart you already are.