5 ms·

Something about running your own password manager server seems very risky to me.

sneak 6y ago
The desktop[1] and mobile clients have a local database, so if the server is offline, you still have all of your data, you just can't sync. [1]: Note that the Bitwarden desktop client has a major remote code execution vulnerability that the developer has closed WONTFIX, so I don't recommend running the stock one without patching that out (as well as the spyware they embed in it).
- teekert 6y ago
  Any more information on your claims? This is the first time I hear of this...
  - sneak 6y ago
    https://github.com/bitwarden/desktop/issues/552 https://github.com/bitwarden/desktop/issues/552
    - teekert 6y ago
      Ah yes, the trust-the-developers-blindly vs patch asap vs supply chain attack risks. I wonder if we have any data on what is best. I once had to re-do a Drupal install because it was very likely already being abused. Would have liked immediate auto-update in that case. Ah well.
      - sneak 6y ago
        Password managers and OSes are things that I do not want automatically updating at the whims of some remote/foreign party whom I have never met and is bound by a set of responsibilities and laws with which I am entirely unfamiliar. Network services open to the internet at large are a horse of a different color. Ultimately, though, they could just ask. Most users probably want autoupdate, and they can opt in to that if they so desire. It's really a matter of consent, and forcing decisions down users' throats. Most people probably don't understand or believe that they are granting these applications' vendors permanent remote access to their computer. Honestly, I wish it were only a matter of trusting the developers. Unfortunately, it's a matter of trusting the developers, anyone from anywhere in the world who can compromise their keys/credentials, and anyone in meatspace who can coerce them to misuse those keys/credentials (such as military, police, et c). That, it turns out, is a rather large set of people, especially when you factor in the number of state level actors from every country big enough to have an intel agency sufficiently competent to own some small software house full of c# weenies running windows (the bitwarden devs).
        teekert 6y ago
        And yet you are using a product at the whims of some remote/foreign party whom you have never met and is bound by a set of responsibilities and laws with which you are entirely unfamiliar. I get where you are coming from, but you clinking "update" in stead of the dev does not guarantee the safety of the update.
        sneak 6y ago
        This is a false dichotomy. Nobody is claiming that mindlessly clicking "update" guarantees safety. I run a private fork of the bitwarden client, anyway. Their stock one partially trusts the iteration count of the PBKDF provided by the server, and can be tricked into sending a low-iteration hash of the master password.
      - UncleMeat 6y ago
        It isn't universal, but browsers surely provide a good case study here. Most of them auto-update today. In the past, exploitation via bugs where patches existed but people didn't update was measurably common. Supply chain attacks against autoupdating browsers haven't really materialized. If the goal is to prevent the most volume of exploitation, autoupdaters clearly win.
        sneak 6y ago
        Browser vendors have teams of experienced and professional security engineers several orders of magnitude larger than the entire Bitwarden organization. They're also bound by US law.
- bri3d 6y ago
  Not linking to the "major RCE vulnerability" is sensationalist posting at its finest. I can assume you are referring to... the automatic updater? https://github.com/bitwarden/desktop/issues/552 https://github.com/bitwarden/desktop/issues/552
  - ryan29 6y ago
    What other options would there even be for updates? That bug report describes every updater I've ever seen.
    - sneak 6y ago
      You are misunderstanding the issue. It's not asking before the update (as most programs that prompt you to update do). By the time that dialog box is displayed, the application has already replaced itself on disk (with code chosen arbitrarily by the bitwarden developers, or anyone in possession of their credentials), and the new code will be executed automatically without user intervention the next time the app is launched, which happens automatically if the computer is rebooted (like if there is a momentary power failure, or you hit "okay" on an OS update, or your battery dies and later you plug it back in to power). This grants the developers (as well as anyone who can compromise their credentials) unlimited remote access to your entire password vault the next time you unlock it.
      - bri3d 6y ago
        Sure, I see where you're coming from. I think your approach makes you come off as not very credible, though. Plus, it puts developers on the defensive and won't cause them to cooperate. A simple "I'm not comfortable with code on my machine being updated remotely without my approval, because I believe an attacker could infiltrate the supply chain" explains the problem you're having more precisely and turns into a simple feature request (turn off the auto-updater - which is already possible, as documented in that thread!) rather than trying to convince an entire industry that a commonly accepted practice (installation of signed remote updates) amounts to 0day RCE by putting them on the defensive.
      - 6y ago

The desktop[1] and mobile clients have a local database, so if the server is offline, you still have all of your data, you just can't sync. [1]: Note that the Bitwarden desktop client has a major remote code execution vulnerability that the developer has closed WONTFIX, so I don't recommend running the stock one without patching that out (as well as the spyware they embed in it).

teekert 6y ago
Any more information on your claims? This is the first time I hear of this...
- sneak 6y ago
  https://github.com/bitwarden/desktop/issues/552 https://github.com/bitwarden/desktop/issues/552
  - teekert 6y ago
    Ah yes, the trust-the-developers-blindly vs patch asap vs supply chain attack risks. I wonder if we have any data on what is best. I once had to re-do a Drupal install because it was very likely already being abused. Would have liked immediate auto-update in that case. Ah well.
    - sneak 6y ago
      Password managers and OSes are things that I do not want automatically updating at the whims of some remote/foreign party whom I have never met and is bound by a set of responsibilities and laws with which I am entirely unfamiliar. Network services open to the internet at large are a horse of a different color. Ultimately, though, they could just ask. Most users probably want autoupdate, and they can opt in to that if they so desire. It's really a matter of consent, and forcing decisions down users' throats. Most people probably don't understand or believe that they are granting these applications' vendors permanent remote access to their computer. Honestly, I wish it were only a matter of trusting the developers. Unfortunately, it's a matter of trusting the developers, anyone from anywhere in the world who can compromise their keys/credentials, and anyone in meatspace who can coerce them to misuse those keys/credentials (such as military, police, et c). That, it turns out, is a rather large set of people, especially when you factor in the number of state level actors from every country big enough to have an intel agency sufficiently competent to own some small software house full of c# weenies running windows (the bitwarden devs).
      - teekert 6y ago
        And yet you are using a product at the whims of some remote/foreign party whom you have never met and is bound by a set of responsibilities and laws with which you are entirely unfamiliar. I get where you are coming from, but you clinking "update" in stead of the dev does not guarantee the safety of the update.
        sneak 6y ago
        This is a false dichotomy. Nobody is claiming that mindlessly clicking "update" guarantees safety. I run a private fork of the bitwarden client, anyway. Their stock one partially trusts the iteration count of the PBKDF provided by the server, and can be tricked into sending a low-iteration hash of the master password.
    - UncleMeat 6y ago
      It isn't universal, but browsers surely provide a good case study here. Most of them auto-update today. In the past, exploitation via bugs where patches existed but people didn't update was measurably common. Supply chain attacks against autoupdating browsers haven't really materialized. If the goal is to prevent the most volume of exploitation, autoupdaters clearly win.
      - sneak 6y ago
        Browser vendors have teams of experienced and professional security engineers several orders of magnitude larger than the entire Bitwarden organization. They're also bound by US law.
bri3d 6y ago
Not linking to the "major RCE vulnerability" is sensationalist posting at its finest. I can assume you are referring to... the automatic updater? https://github.com/bitwarden/desktop/issues/552 https://github.com/bitwarden/desktop/issues/552
- ryan29 6y ago
  What other options would there even be for updates? That bug report describes every updater I've ever seen.
  - sneak 6y ago
    You are misunderstanding the issue. It's not asking before the update (as most programs that prompt you to update do). By the time that dialog box is displayed, the application has already replaced itself on disk (with code chosen arbitrarily by the bitwarden developers, or anyone in possession of their credentials), and the new code will be executed automatically without user intervention the next time the app is launched, which happens automatically if the computer is rebooted (like if there is a momentary power failure, or you hit "okay" on an OS update, or your battery dies and later you plug it back in to power). This grants the developers (as well as anyone who can compromise their credentials) unlimited remote access to your entire password vault the next time you unlock it.
    - bri3d 6y ago
      Sure, I see where you're coming from. I think your approach makes you come off as not very credible, though. Plus, it puts developers on the defensive and won't cause them to cooperate. A simple "I'm not comfortable with code on my machine being updated remotely without my approval, because I believe an attacker could infiltrate the supply chain" explains the problem you're having more precisely and turns into a simple feature request (turn off the auto-updater - which is already possible, as documented in that thread!) rather than trying to convince an entire industry that a commonly accepted practice (installation of signed remote updates) amounts to 0day RCE by putting them on the defensive.
    - 6y ago