5 ms·

Encrypted communication relies on keys generated by computers. They have significantly more bits of entropy than a master password produced by a human.

• zokier 7y ago
  Master passwords should also be generated by computers (or dice if you want to go that route)
• prophesi 7y ago
  The major problem with passwords is reuse. Nobody's out there trying to bruteforce your passwords, unless you're a state-level threat. In reality, they'll be using your password from a database leak from a different service and programmatically try a few variants of it before moving on to the next target. For physical access (like logging into a PC w/ SSH disabled), you only need 4 words to have sufficient entropy. Use 7 words if you want to reach a level of entropy that would literally cost decades of computing power to bruteforce. That said, the 7 word passphrase should be generated by a computer anyways. Also wanted to point out that the phrase "encryption is a reversible process" is hilarious. Encryption is literally about making it _as difficult as possible_ to reverse its process. Bruteforcing is not reversing the process.
  • 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.