5 ms·

BitWarden doesn't get "complete access to your digital life", they get an encrypted blob. It's not materially different than storing your KeePass vault in the

by TillE 4y ago

BitWarden doesn't get "complete access to your digital life", they get an encrypted blob. It's not materially different than storing your KeePass vault in the cloud.

mort96 4y ago
There's still trust there. You're writing the key to decrypt everything into their web interface if you ever use it (vault.bitwarden.com). If they wanted, they could really get access to everything in your bitwarden vault.
- dcow 4y ago
  That's why open source is important. You can audit them and verify that they are behaving in a trustworthy manner.
  - Kimcha 4y ago
    Not if you are using their cloud version instead of the open source self hosted server. The code they are running does have to be the code they are publishing. And if someone compromises their cloud servers, they could also modify it to log the passwords entered.
    - tracker1 4y ago
      Then host your own.
    - dcow 4y ago
      Yes we can degenerate into inordinate amounts of rabbit holes. For 1, you can audit the JS that runs on your browser, it's not hiding (so it's not strictly fair to say that just because you loaded a webpage in your browser from their server it can't be trusted). And anyway, generally, your argument holds for any software interaction ever. GH doesn't have to ship you the repo that you browsed on the web client. A malicious actor could have compromised their infra and be serving fake code in the web UI but have added all sorts of malware to the stuff you download. Apple app store doesn't eve ship you the exact binary the developer uploaded. Scary. At some point you have to decide which threat vectors you actually care about. Give me a scenario and I can tell you how someone can theoretically attack it and why you're not safe. The only thing you can be 100% sure about is manually auditing every single release at the source level and building it yourself.
      - hn92726819 4y ago
        If you run keepass in a cgroup with no networking (or blocking in/outbound traffic in windows firewall) or extra disk access, your attack vector shrinks considerably. That's not particularly difficult to do, while it is to audit js on every single bitwarden page load
      - getcrunk 4y ago
        Well even then you have to make sure your compiler isn’t playing tricks on you. So compile your compiler from source … oh wait. Then you have your cpu microcode, firmware, security coprocessors. Trusting trust
    - LelouBil 4y ago
      They have a paper about their architecture. Basically, your master password is never sent, and everything is encrypted and decrypted locally. You can't audit the server side code, but you can audit the client (and compile it from source) to make sure that the encryption is local and the master password is not sent.
      - arcastroe 4y ago
        Hah, so I suppose the next step would be a browser extension that performs this auditing on every visit
    - thayne 4y ago
      But your data is encrypted client side. It shouldn't be too difficult to audit thay the client side code matches a build of their original sources.
  - mort96 4y ago
    I can't audit their server-side code. Even if it's open source, it's impossible to verify that the software which the server is running is identical to the open source version, or that there's no proxy in between you and the sever which logs the passwords, or some debugger attached which inspects the passwords in memory as people log in.
    - 3np 4y ago
      The proxy would only see encrypted blobs; the client (which afaiui can be compiled and run locally despite using their hosted service) never sees the passwords in clear. As long as the client and cryptography are uncompromised, the server only gets metadata.
    - LelouBil 4y ago
      They have a paper about their architecture. Basically, your master password is never sent, and everything is encrypted and decrypted locally. You can't audit the server side code, but you can audit the client (and compile it from source) to make sure that the encryption is local and the master password is not sent.
Fnoord 4y ago
Microsoft too, since Bitwarden uses Azure. I think its find.

by TillE 4y ago

BitWarden doesn't get "complete access to your digital life", they get an encrypted blob. It's not materially different than storing your KeePass vault in the cloud.

mort96 4y ago

There's still trust there. You're writing the key to decrypt everything into their web interface if you ever use it (vault.bitwarden.com). If they wanted, they could really get access to everything in your bitwarden vault.

dcow 4y ago
That's why open source is important. You can audit them and verify that they are behaving in a trustworthy manner.
- Kimcha 4y ago
  Not if you are using their cloud version instead of the open source self hosted server. The code they are running does have to be the code they are publishing. And if someone compromises their cloud servers, they could also modify it to log the passwords entered.
  - tracker1 4y ago
    Then host your own.
  - dcow 4y ago
    Yes we can degenerate into inordinate amounts of rabbit holes. For 1, you can audit the JS that runs on your browser, it's not hiding (so it's not strictly fair to say that just because you loaded a webpage in your browser from their server it can't be trusted). And anyway, generally, your argument holds for any software interaction ever. GH doesn't have to ship you the repo that you browsed on the web client. A malicious actor could have compromised their infra and be serving fake code in the web UI but have added all sorts of malware to the stuff you download. Apple app store doesn't eve ship you the exact binary the developer uploaded. Scary. At some point you have to decide which threat vectors you actually care about. Give me a scenario and I can tell you how someone can theoretically attack it and why you're not safe. The only thing you can be 100% sure about is manually auditing every single release at the source level and building it yourself.
    - hn92726819 4y ago
      If you run keepass in a cgroup with no networking (or blocking in/outbound traffic in windows firewall) or extra disk access, your attack vector shrinks considerably. That's not particularly difficult to do, while it is to audit js on every single bitwarden page load
    - getcrunk 4y ago
      Well even then you have to make sure your compiler isn’t playing tricks on you. So compile your compiler from source … oh wait. Then you have your cpu microcode, firmware, security coprocessors. Trusting trust
  - LelouBil 4y ago
    They have a paper about their architecture. Basically, your master password is never sent, and everything is encrypted and decrypted locally. You can't audit the server side code, but you can audit the client (and compile it from source) to make sure that the encryption is local and the master password is not sent.
    - arcastroe 4y ago
      Hah, so I suppose the next step would be a browser extension that performs this auditing on every visit
  - thayne 4y ago
    But your data is encrypted client side. It shouldn't be too difficult to audit thay the client side code matches a build of their original sources.
- mort96 4y ago
  I can't audit their server-side code. Even if it's open source, it's impossible to verify that the software which the server is running is identical to the open source version, or that there's no proxy in between you and the sever which logs the passwords, or some debugger attached which inspects the passwords in memory as people log in.
  - 3np 4y ago
    The proxy would only see encrypted blobs; the client (which afaiui can be compiled and run locally despite using their hosted service) never sees the passwords in clear. As long as the client and cryptography are uncompromised, the server only gets metadata.
  - LelouBil 4y ago
    They have a paper about their architecture. Basically, your master password is never sent, and everything is encrypted and decrypted locally. You can't audit the server side code, but you can audit the client (and compile it from source) to make sure that the encryption is local and the master password is not sent.

Fnoord 4y ago

Microsoft too, since Bitwarden uses Azure. I think its find.