6 ms·

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 no

by bsza 7y ago

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 https://aka.ms/win10rng [2] https://pthree.org/2014/07/21/the-linux-random-number-generator/ https://pthree.org/2014/07/21/the-linux-random-number-genera... [3] https://security.stackexchange.com/questions/214784/can-ads-on-a-page-read-my-password https://security.stackexchange.com/questions/214784/can-ads-...

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

by bsza 7y ago

prophesi 7y ago

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.

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