4 ms·

"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

by bsza 7y ago

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

prophesi 7y ago
> 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.
- bsza 7y ago
  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.
  - prophesi 7y ago
    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.

by bsza 7y ago

prophesi 7y ago

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

bsza 7y ago
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.
- prophesi 7y ago
  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.