I don't think encryption being reversible is anything to be laughed at. This leads to a lot of other caveats. For example, the length of the plaintext is in correlation with the length of the ciphertext. From this, an attacker could potentially tell if a managed password is short enough to be even worth trying to brute-force. And yes, passwords could be padded, yes, I'm oversimplifying things here, but my point is, in some cases encryption is not the best tool.

And this is one of them. Because what particularly annoys me about this whole thing is that there already are perfectly good and well-supported authentication protocols, like SRP [1], that don't involve you sending your password to anyone. If we all just used that, password reuse wouldn't be something to worry about in the first place. Sadly, a lot of people saw it as trying to be a replacement for HTTPS (it is not), so it never really caught on, which is a pity IMO. The client side could be a built-in module in browsers or something like that.

[1] https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

PBKDF2 solves all of those issues, which LessPass uses. I think I understand what you're trying to say, though; it _is_ insecure to rely on the user for entropy. If the master password is weak, that consequently weakens the entropy of the generated passwords. PBKDF2 does a lot to add entropy to offset this issue. From there, you can generate passwords of any desired length using the entropy of this PBKDF2 key. And brute-forcing these generated passwords won't tell you anything about your master password.

SRP isn't a perfectly good and well-supported protocol. It was made back when all sites used HTTP, and has taken years to finally get to a revision that isn't broken. You'd just be adding unnecessary complexity for authentication, when it's completely secure to send your password over HTTPS. And if the database was compromised, the attacker can still bruteforce the password verifier to impersonate the user. Yes, it's good that they won't be able to derive the actual password, but that shouldn't be an issue if people didn't reuse passwords in the first place.

At the end of the day, you're still using encryption if authentication is involved.

Small correction: an attacker needs a password verifier AND the server private key to brute-force an SRP password. Also, I think it's great that there are no known attacks other than brute force - even if it took several iterations to get there. As you said, the more realistic failure modes are data leaks, like passwords getting into the log files, or getting hashed without a salt, or not getting hashed at all. All of which are covered by SRP by design.

Sure, but if the database is compromised, the attacker will have the server's private key. They can still bruteforce passwords, except against SRP's less battle-tested hashing algorithm.

It's simply a lot more complexity for essentially no benefit. You now need to trust both the code on the server _and_ on the client to do the steps properly. Sending a password over HTTPS and hashing it is much easier for a developer to implement. There's definitely room for the password to accidentally be logged, but the same applies to SRP's password verifier, or the client's secret key, et cetera.

And if this is in the browser, then there's the issue of figuring out where to get an adequate amount of entropy on the client when generating the private key, or finding a polyfill to ensure keys are generated properly across browsers, or making sure you sandbox the code so that any third-party scripts can't access it. The general consensus is to avoid doing any crypto in the browser. These are just a few of the many reasons why people don't hash passwords on the client-side before sending them to the server.

I mean, leaking an SRP verifier into the logs is analogous to leaking a salted password hash. (Same story if a client key is leaked, since replay attacks are not possible.) That is still 1000x better than a plaintext password leak. Which happens... how often again? All it takes is one oversight by one developer and one rushed code review. Addressing arguably the most common way passwords are stolen nowadays is not what I would summarize as "essentially no benefit". And no, you don't have to trust the server to get that protection. Your password never leaves you, that's the point. An entire class of attack vectors just doesn't exist here. Including phishing attacks - if the browser gives the user unambiguous visual clue that the auth is happening through SRP.

About browsers: The default CSPRNG on Win10 and Linux don't need a constant stream of entropy to generate strong random numbers. But just for good measure, both of them incorporate mouse movement [1] [2], among other things. Your other comments assume the client code is in the JS, which I agree is a horrible idea (tangentially related: [3]). That's why I said it should be built into the browser directly (a pipe dream, but still). Though on a second (and rather perverse) thought, even if it's in the website, it will not provide worse security than sending the password... Nothing can provide worse security than that unless you downright "mutilate" the entropy of the credentials. Assuming everything happens over HTTPS, of course. Still, not something I would be proud to publish on github :)

About complexity: Good choice of words; password hash verification is EASIER to do than ZKPP. Not simpler. If you need to supplement it with an online password manager, or very good recall, or 2FA to ensure basic security, that's just pushing complexity onto the user. But I understand how you might see that as an unfair comparison, given that all of these things can benefit ZKPP as well. Just not as important - assuming the client side is properly implemented and the user chooses and handles the password with care.

Oh, and SRP doesn't define its "own" hash function. I've never heard of a protocol that does. Such things should always be configurable and left to the security architect's decision.

[1] https://aka.ms/win10rng

[2] https://pthree.org/2014/07/21/the-linux-random-number-genera...

[3] https://security.stackexchange.com/questions/214784/can-ads-...

Yes, verifying the hash of a password is simpler than SRP. You'll still need a password manager and 2FA with SRP. The user will still be entering in their password into a form-field on the client. You'll still need 2FA to make sure it isn't a credential stuffing attack, or someone who phished them. And yes, you can still be phished with SRP. SRP doesn't mean there is no password. You'll still want a different password for every service.

At the end of the day, I'd much rather advise developers to hash & salt than hope that they can properly implement the 7 or 8 step process of SRP. That's an insane amount of complexity for authentication, with plenty of room for mistakes to be made. Developers have enough trouble getting even OAuth to work.

SRP gives you the same amount of security (arguably less, if the user chooses a weak password and/or the client code doesn't properly stretch the keys) as the conventional hash & salt.

"The user will still be entering in their password into a form-field on the client."

You are looking at this problem based on what practices we currently have in place. Entering a password into an HTML form is NOT SECURE, period. It will never be. That practice needs to change first. Browsers already have built-in authentication prompts, for this exact purpose. But they're ugly, so no one uses them. Tough. To secure the client, one would need a browser extension that gives you a similar and distinct prompt with all the client-side logic in it. While this still leaves room for phishing, it is not enough in itself; you have to combine it with brute force. That alone is a huge improvement. It's not the "same amount of security". It would be lightyears ahead of what we do right now.

Now, what SRP does is prevent the server from mishandling the password. That means the server has no way of checking whether your password is strong enough. And why would you want it to? That's precisely the kind of mentality I wish just went away. Don't rely on someone else's computer for your own security.

I'm sure SRP has its own shortcomings, and some implementations are probably still buggy to this day. But that doesn't make hash verification one bit less horrible. Being reducible to a salted hash is about the worst failure mode there is for a ZKPP/PAKE implementation, so even if you make a mistake you're not worse off than what you started with. Also, two PAKE solutions seemingly more well designed than SRP have been published recently, SPAKE2+ and OPAQUE. I'm still trying to understand them, but I really like that OPAQUE's verifier is derived with symmetric encryption keyed with the registration key on the server side (as opposed to SRP, where it is a discrete logarithm puzzle), and if I'm not mistaken that takes care of quantum-resistance of the stored state as well (which understandably was not much of a concern back when SRP was designed).

> Entering a password into an HTML form is NOT SECURE, period.

What I meant by needing the user to enter a password (whether in a web app or native app) is that the user will still need to use a password manager and 2FA for decent security in the case that their password is compromised elsewhere. And no, you don't have to combine it with bruteforce if someone knows the password you use on an app that utilizes SRP. So it's not lightyears from what we have now. If you have the password, you can log in, whether the server uses OPAQUE or simply checks the hash.

A browser extension is still insecure third-party JS code. I honestly think there's no way to securely implement it for browsers, but it'd work well in native apps.

> Don't rely on someone else's computer for your own security.

Precisely. Use a password manager and assume the server is going to be compromised one day. Assume you might be phished one day, so you shouldn't use the same password for everything. That's the right mindset.

A salted hash is what all ZKPP implementations end up with. You can still figure out the user's password by bruteforcing the password verifier, because it's the hashed result of the ZKP's algorithm. My case in point is that you're achieving the same level of security as HTTPS + salted hash except in 7+ steps, each step leaving room for improper implementation.

Compromised where elsewhere? I control my password, so I know exactly where it goes and doesn't go. And the only place it ever goes is the little green box in my zero knowledge password extension (or native app if you prefer). I, as the user, have complete control over my own security. If my password was compromised in any way other than brute force, I can be 100% sure it was my own fault. Maybe I didn't inspect the source code well enough, maybe I talk in my sleep, but it's all on me. Saying that someone can obtain my ZKPP password through a different channel is just as nonsensical as saying that someone could get their hands on my password manager's master password if I once made an account on a pizzeria's site with the same credentials. Well, I shouldn't have.

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.

Perhaps you have a keylogger on your computer. Or a malicious app was able to access your clipboard. Or a third-party script on the site hijacked the form submission (Magecart, which is still an issue to this day). Or perhaps you're using a native app that isn't open-source, and they send your credentials to their servers to create their own list of passwords for credential stuffing elsewhere. There are many possible channels to be compromised. Sure, these are "user errors," but people have to use proprietary apps and websites for their day-to-day life. And people still get phished.

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.

If I had a keylogger or other spyware, even my password manager's master password wouldn't be safe, so that line of reasoning still doesn't sound convincing to me. :) Only 2FA could prevent that, and I don't mind using 2FA as much as using password managers because it actually brings in something of value, something other than a "what you know".

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.)

You know, I'm almost sold on it. I still think it's a bad idea to use it in the browser, but for native apps/games, some of the pros could be really nice (particularly client-side hashing).

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.

Glad I could get you a bit more interested in this kind of approach. Your summary makes sense to me, though admittedly it is damn hard to reason about the security of these things correctly. Getting the client to do the hard work really is an added bonus, now that you mention.

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.