8 ms·

I think online password managers are a bad enough idea already. You should never send your password to anyone (except to the service you're using of course). No

by bsza 7y ago

I think online password managers are a bad enough idea already. You should never send your password to anyone (except to the service you're using of course). Not even in encrypted form, since encryption is a reversible process.

pvg 7y ago
By that logic, you shouldn't rely on encrypted communication at all since encryption is a reversible process.
- bsza 7y ago
  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
onion2k 7y ago
since encryption is a reversible process Encryption is a reversible process if you have the key. If you don't then it is effectively irreversible. It's definitely secure enough that we've built the entire internet and banking systems around it, so it's probably secure enough for your HN password.
- bsza 7y ago
  "we've built the entire internet and banking systems around it" Yes, but in those scenarios we use keys that are truly random. Deriving a symmetric key from a password and encrypting another password with it is simply never going to be as secure. You're better off storing it locally.
  - soraminazuki 7y ago
    In fact, some password managers (well, at least 1Password) do generate a random secret key that you're required to provide at login in addition to your master password.
    - bsza 7y ago
      At which point, I guess, the key has to be either short enough that you can remember it, or stored on a portable device.
      - soraminazuki 7y ago
        You need an already logged-in device or a printout of the secret key to login. The former isn't much of a concern because if an attacker has access to a logged-in device, you're screwed anyways. The latter would require physical access to your home, and the same applies here too.
soraminazuki 7y ago
It's a vast improvement over the traditional alternative of people reusing passwords across sites IMHO. It's hard enough to get non-technical people to use passwords managers. The chance of getting people to use a password manager without a usable syncing capability is virtually none.
- bsza 7y ago
  It is an improvement, for sure. And probably good enough for the average user. On the other hand, if convenience is important, then I see no obvious difference between an online password manager and the OP's solution. In both cases, the security of your password vault depends directly on the security of your master password.
  - soraminazuki 7y ago
    I don't think that assumption is true because it should be far more easier to brute force the master password of a deterministic password manager. Worse, the OP's solution accepts "password" as a master password, which means that many, many people are going to have the same generated passwords if this gets widely adopted.
    - bsza 7y ago
      That's... not reassuring. Though I would still argue that that is more of an implementation issue, not a deal-breaker for the general idea. And there are many KDF variants that (claim to) offer protection against brute force, so that's not necessarily an issue either (but I do agree it sounds risky).
whatl3y 7y ago
I built this to allow me to manage my passwords on my machine without sending them to any third party. The data lives on your machine encrypted with a master password, but the encrypted data never has to leave your machine or network: https://github.com/whatl3y/hide https://github.com/whatl3y/hide I need it almost daily. Being a developer and almost always in a terminal it’s convenient to retrieve a password really quick when needed.

by bsza 7y ago

pvg 7y ago

By that logic, you shouldn't rely on encrypted communication at all since encryption is a reversible process.

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

onion2k 7y ago

since encryption is a reversible process Encryption is a reversible process if you have the key. If you don't then it is effectively irreversible. It's definitely secure enough that we've built the entire internet and banking systems around it, so it's probably secure enough for your HN password.

bsza 7y ago
"we've built the entire internet and banking systems around it" Yes, but in those scenarios we use keys that are truly random. Deriving a symmetric key from a password and encrypting another password with it is simply never going to be as secure. You're better off storing it locally.
- soraminazuki 7y ago
  In fact, some password managers (well, at least 1Password) do generate a random secret key that you're required to provide at login in addition to your master password.
  - bsza 7y ago
    At which point, I guess, the key has to be either short enough that you can remember it, or stored on a portable device.
    - soraminazuki 7y ago
      You need an already logged-in device or a printout of the secret key to login. The former isn't much of a concern because if an attacker has access to a logged-in device, you're screwed anyways. The latter would require physical access to your home, and the same applies here too.

soraminazuki 7y ago

It's a vast improvement over the traditional alternative of people reusing passwords across sites IMHO. It's hard enough to get non-technical people to use passwords managers. The chance of getting people to use a password manager without a usable syncing capability is virtually none.

bsza 7y ago
It is an improvement, for sure. And probably good enough for the average user. On the other hand, if convenience is important, then I see no obvious difference between an online password manager and the OP's solution. In both cases, the security of your password vault depends directly on the security of your master password.
- soraminazuki 7y ago
  I don't think that assumption is true because it should be far more easier to brute force the master password of a deterministic password manager. Worse, the OP's solution accepts "password" as a master password, which means that many, many people are going to have the same generated passwords if this gets widely adopted.
  - bsza 7y ago
    That's... not reassuring. Though I would still argue that that is more of an implementation issue, not a deal-breaker for the general idea. And there are many KDF variants that (claim to) offer protection against brute force, so that's not necessarily an issue either (but I do agree it sounds risky).

whatl3y 7y ago

I built this to allow me to manage my passwords on my machine without sending them to any third party. The data lives on your machine encrypted with a master password, but the encrypted data never has to leave your machine or network: https://github.com/whatl3y/hide https://github.com/whatl3y/hide I need it almost daily. Being a developer and almost always in a terminal it’s convenient to retrieve a password really quick when needed.