And so, users shouldn't trust websites. That's why the browser is sandboxed. They shouldn't trust proprietary apps either, but now Mac/Windows users are accustomed to letting apps elevate their privileges upon installation. Assume they won't handle your credentials securely, and you'll be better off when security does inevitably break somewhere down the line.
You're wanting an ideal world where every service everywhere is using some sort of ZKPP for authentication, both the client and server are open source with reproducible builds, have security audits, and their users don't reuse passwords. I would love this too, but it's not reasonable. There's a huge educational and governmental gap for society to get there.
We'll always need password managers and 2FA; globally-enforced ZKPP's still won't stop that. Perhaps there's a use-case for them elsewhere that will be revolutionary, like end-to-end encryption with messaging apps. But for authentication? Just send it over HTTPS.
Honestly, I don't think this would require such a big change/re-education, but it's hard to tell. Historically, much bigger changes in IT security were implemented with success - like the widespread use of SSL/TLS itself, even though that consists of more than 7 steps as well, and aims to achieve basically the same thing as PAKE, minus the client auth being obligatory (or that can be a plus, depending on how you view it). Instead of an ideal world, I'd say 'alternative'. Hmm. So maybe SRP was all about succeeding HTTP after all...
That said, I wouldn't mind at all if a PAKE initiative started small, with a handful of websites. If they knew what they were doing, of course. That alone wouldn't eliminate the need for password managers and the like, but at least one less password I'd need to regularly check on HaveIBeenPwned. (Okay, that's a lie. I'm never checking them anyway. All talk and no action.)
ZKPP's
Pros
- You can make sure the server won't mishandle the password.
- You can let the client do the hashing, which helps alleviate server strain. You can set the number of hash iterations to a much higher amount than you'd typical use on a server.
- You've got a secure connection for client/server communication now; this in particular can likely find a revolutionary use-case, perhaps in gaming.
Cons
- Your developers have to learn how to go through the 7+ steps properly, until frameworks for it crop up.
- Less battle-tested: there may be more bugs and exploits in whichever protocol you choose due to how many less eyes are on it.
- Developers may choose a really weak hashing algorithm.
It would be pretty sweet for browsers to have one of the ZKPP's built-in, where the javascript can't touch the user's password or the code for generating the keys & initiating the handshake.
I think this is an exciting field of research - if in practice little more than a curiosity at this time -, and I expect great results to come out of it in the near future.
Conversely, if an attacker obtains part of a server log from example.com, and my password is in there, they can impersonate me on example.com. It doesn't help that they can't impersonate me elsewhere because I don't reuse passwords. The damage is already done. That's because I trusted example.com to handle my credentials securely, and they didn't. I, as the user, had zero say about how secure the authentication process should be.
While I wholeheartedly agree that using different passwords, having 2FA enabled etc. is always better than not doing so, what I don't like is that these additions came about as artifacts of the crappy way we handle authentication. I want them to be a nice-to-have, an extra line of defense, not forced solutions born out of necessity.