3 ms·

I've never understood why anyone who takes security seriously would even consider a non-self-hosted (and non-open-source) password manager, especially after the

by lisper 5y ago

I've never understood why anyone who takes security seriously would even consider a non-self-hosted (and non-open-source) password manager, especially after the recent Apple shenanigans. If it's not open-source and self-hosted then your security is entirely dependent on the good will of your provider. If they decide to screw you, they can. And it's not just the good will of the people running your provider today that you have to bet on, it is the continued good will of whoever ends up running your provider tomorrow or after they get acquired. It seems like a bad bet to me in the long run.

YPPH 5y ago
Convenience. A self-hosted password manager really shouldn't be exposed to the internet. If you are making it accessible over the internet, it's a far greater security threat imo. You're just not going to be able to keep it up to the same security standards as a large production install, like what the Bitwarden folks have going. Needing to VPN or SSH tunnel into my home network each time I need a password is far too inconvenient. Not to mention the spared effort in not needing to regularly back up your vault or worrying about keeping the service available.
- lisper 5y ago
  If it's properly encrypted you should be able to publish it on github and still be more secure than entrusting it to a third party.
  - YPPH 5y ago
    Publishing your vault of passwords on a public GitHub repository seems like a pretty bad idea, no matter how well you trust the client-side encryption code. I'm no expert on the subject, but I suspect these password managers use a sophisticated mechanism of authentication (for accessing the vault) as well as encrypting of the actual contents of the vault. The effect of this means that Bob's encrypted vault cannot be downloaded by an attacker without the attacker first authenticating to the server.
    - lisper 5y ago
      And why do you think that authentication + encryption is going to be more secure than encryption alone? Either way, there's a secret. If you know the secret you can access the data and if you don't you can't. The UI/UX trappings of the mechanism don't change this fundamental dynamic. What does change the dynamic is if you allow a third party to control the code that you run.
      - YPPH 5y ago
        2FA is engaged at the authentication stage, so knowing the vault passphrase may not be sufficient. Further, allowing anyone to download my encrypted vault just feels really uncomfortable and unnecessary.
        lisper 5y ago
        You can use 2FA to encrypt. OK, it would be 2FE, not 2FA, but it's the same idea. Just encrypt using a Diffie-Helman key derived from a secret contained on a device. (Of course, if you're going to do this, you could just as well keep the vault itself on the device.) > Further, allowing anyone to download my encrypted vault just feels really uncomfortable and unnecessary. It is unnecessary. I said you could publish your vault on github and still be more secure than a third-party provider. I didn't say you should do this. Of course you should try to keep your vault away from prying eyes. But you should not rely on this for your security. You should only ever rely on one thing for data security, and that is the integrity of your secrets, which should be small enough to be stored in your brain or in a device that allows them to be used without being read (2FA/E). That's the whole point of encryption.
    - Barrin92 5y ago
      >Publishing your vault of passwords on a public GitHub repository seems like a pretty bad idea, no matter how well you trust the client-side encryption code. If it's properly encrypted you can display your encrypted vault on a Times Square billboard and it doesn't matter, it's like that physics experiment[1], looks scary but there's nothing unsafe about it. [1]https://youtu.be/xXXF2C-vrQE https://youtu.be/xXXF2C-vrQE
- miked85 5y ago
  That is why the local vault option was the best in my mind, and then using DropBox/Resilio/etc to sync. It is very unfortunate that they are no longer supporting local vaults in the next version.
pvg 5y ago
if it's not open-source and self-hosted then your security is entirely dependent on the good will of your provider. It's because neither of these conditions are really true - you'd have to assume that source code is only way to assess the security of software and that end-to-end encryption doesn't actually work.
- lisper 5y ago
  That depends on what you mean by "end-to-end encryption doesn't actually work". Of course E2EE works in principle. The problem is: how can I know that the code I am running is in fact a properly implemented E2EE system if I don't trust the vendor and I can't audit the code?
  - pvg 5y ago
    If you don't trust the vendor, don't let them handle your passwords, obviously. But the security properties non-open-source code are routinely analyzed and vulnerabilities found, etc. Plus the track records of the various solutions, a cartesian product of open/closed source, 'hosted' or not, etc speak for themselves.
    - lisper 5y ago
      > If you don't trust the vendor, don't let them handle your passwords, obviously. The problem is you not only have to trust your vendor today, but you also have to trust them tomorrow. Every vendor is one acquisition or compromised senior executive or engineer [1] away from becoming untrustworthy even if they started out being perfectly trustworthy. Assessing present trustworthiness is hard enough. Assessing future trustworthiness is obviously impossible. [1] They don't even have to be compromised. All they have to do is make a bad decision. Apple, the company that built an entire marketing campaign on trust, is now installing spyware on its devices.
      - pvg 5y ago
        Right, but this applies to big piles of security-critical software in general - a near tautology. It's really an argument in favour of my position that neither open-sourcedness nor hostedness are useful criteria in evaluating the security and fitness-for-purpose of a password manager.
mekster 5y ago
Because they put their effort for their reputation and pays millions to hire people to look after their security. If the "good will" is making them money, I guess you can count on it. And you think your own hosted version that you're only looking after is that much better?
- lisper 5y ago
  > If the "good will" is making them money, I guess you can count on it. On that view, they should be willing to sell your passwords to anyone willing to pay them more than you are. > And you think your own hosted version that you're only looking after is that much better? Yes. Because I know that I won't sell to the highest bidder.

by lisper 5y ago

YPPH 5y ago

Convenience. A self-hosted password manager really shouldn't be exposed to the internet. If you are making it accessible over the internet, it's a far greater security threat imo. You're just not going to be able to keep it up to the same security standards as a large production install, like what the Bitwarden folks have going. Needing to VPN or SSH tunnel into my home network each time I need a password is far too inconvenient. Not to mention the spared effort in not needing to regularly back up your vault or worrying about keeping the service available.

lisper 5y ago
If it's properly encrypted you should be able to publish it on github and still be more secure than entrusting it to a third party.
- YPPH 5y ago
  Publishing your vault of passwords on a public GitHub repository seems like a pretty bad idea, no matter how well you trust the client-side encryption code. I'm no expert on the subject, but I suspect these password managers use a sophisticated mechanism of authentication (for accessing the vault) as well as encrypting of the actual contents of the vault. The effect of this means that Bob's encrypted vault cannot be downloaded by an attacker without the attacker first authenticating to the server.
  - lisper 5y ago
    And why do you think that authentication + encryption is going to be more secure than encryption alone? Either way, there's a secret. If you know the secret you can access the data and if you don't you can't. The UI/UX trappings of the mechanism don't change this fundamental dynamic. What does change the dynamic is if you allow a third party to control the code that you run.
    - YPPH 5y ago
      2FA is engaged at the authentication stage, so knowing the vault passphrase may not be sufficient. Further, allowing anyone to download my encrypted vault just feels really uncomfortable and unnecessary.
      - lisper 5y ago
        You can use 2FA to encrypt. OK, it would be 2FE, not 2FA, but it's the same idea. Just encrypt using a Diffie-Helman key derived from a secret contained on a device. (Of course, if you're going to do this, you could just as well keep the vault itself on the device.) > Further, allowing anyone to download my encrypted vault just feels really uncomfortable and unnecessary. It is unnecessary. I said you could publish your vault on github and still be more secure than a third-party provider. I didn't say you should do this. Of course you should try to keep your vault away from prying eyes. But you should not rely on this for your security. You should only ever rely on one thing for data security, and that is the integrity of your secrets, which should be small enough to be stored in your brain or in a device that allows them to be used without being read (2FA/E). That's the whole point of encryption.
  - Barrin92 5y ago
    >Publishing your vault of passwords on a public GitHub repository seems like a pretty bad idea, no matter how well you trust the client-side encryption code. If it's properly encrypted you can display your encrypted vault on a Times Square billboard and it doesn't matter, it's like that physics experiment[1], looks scary but there's nothing unsafe about it. [1]https://youtu.be/xXXF2C-vrQE https://youtu.be/xXXF2C-vrQE
miked85 5y ago
That is why the local vault option was the best in my mind, and then using DropBox/Resilio/etc to sync. It is very unfortunate that they are no longer supporting local vaults in the next version.

pvg 5y ago

if it's not open-source and self-hosted then your security is entirely dependent on the good will of your provider. It's because neither of these conditions are really true - you'd have to assume that source code is only way to assess the security of software and that end-to-end encryption doesn't actually work.

lisper 5y ago
That depends on what you mean by "end-to-end encryption doesn't actually work". Of course E2EE works in principle. The problem is: how can I know that the code I am running is in fact a properly implemented E2EE system if I don't trust the vendor and I can't audit the code?
- pvg 5y ago
  If you don't trust the vendor, don't let them handle your passwords, obviously. But the security properties non-open-source code are routinely analyzed and vulnerabilities found, etc. Plus the track records of the various solutions, a cartesian product of open/closed source, 'hosted' or not, etc speak for themselves.
  - lisper 5y ago
    > If you don't trust the vendor, don't let them handle your passwords, obviously. The problem is you not only have to trust your vendor today, but you also have to trust them tomorrow. Every vendor is one acquisition or compromised senior executive or engineer [1] away from becoming untrustworthy even if they started out being perfectly trustworthy. Assessing present trustworthiness is hard enough. Assessing future trustworthiness is obviously impossible. [1] They don't even have to be compromised. All they have to do is make a bad decision. Apple, the company that built an entire marketing campaign on trust, is now installing spyware on its devices.
    - pvg 5y ago
      Right, but this applies to big piles of security-critical software in general - a near tautology. It's really an argument in favour of my position that neither open-sourcedness nor hostedness are useful criteria in evaluating the security and fitness-for-purpose of a password manager.

mekster 5y ago

Because they put their effort for their reputation and pays millions to hire people to look after their security. If the "good will" is making them money, I guess you can count on it. And you think your own hosted version that you're only looking after is that much better?

lisper 5y ago
> If the "good will" is making them money, I guess you can count on it. On that view, they should be willing to sell your passwords to anyone willing to pay them more than you are. > And you think your own hosted version that you're only looking after is that much better? Yes. Because I know that I won't sell to the highest bidder.