5 ms·

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 cor

by bsza 7y ago

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_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

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

by bsza 7y ago

prophesi 7y ago

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.

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