6 ms·

I love this project, but something has always bothered me about it. For something as critical as your entire set of passwords, aren’t you essentially trusting t

I love this project, but something has always bothered me about it. For something as critical as your entire set of passwords, aren’t you essentially trusting this person you’ve never met to not just take all of them when you use the server? For example, one day a malicious maintainer could flip a switch that simply updates the docker image to send thousands of peoples’ entire vault somewhere and then disappear, no?

killingtime74 6y ago
Especially since bitwarden itself is already open source. This is a great learning project probably but not great for use
- joaopms 6y ago
  The greatest thing about this implementation is its simplicity. I actually deployed this server for my personal use because everything lives in one Docker image and not a lot of them like the official implementation. I do understand that the official implementation helps with scalability and more, I just don't need it.
- Nullabillity 6y ago
  The official Bitwarden server depends on MSSQL.
BiteCode_dev 6y ago
Same with basically any part of your infra. What prevents Postgres mainteners to just still all your DB ? Nginx mainteners to redirect your web traffic ? Ultimately, it boils down to a balance between trust in the author, the community or your own checking process.
novium 6y ago
If I'm not mistaken it should be mostly fine as long as you trust the desktop/phone versions of Bitwarden not to send off the (unhashed) key to the server Edit: Noting that there have been discussions about the default number of iterations. https://github.com/bitwarden/jslib/issues/52 https://github.com/bitwarden/jslib/issues/52
- danmur 6y ago
  The main problem I can see is entering your login in the web interface. I still use it though.
- sneak 6y ago
  Note also that the bitwarden desktop app has a remote code execution vulnerability that the developers refuse to fix, which means that the developers can, at any time, replace your local copy of the bitwarden desktop app with a different version that could steal all your passwords in exactly the manner you describe. You can patch the bitwarden client (and also take the opportunity to remove the spyware they have embedded in it, as well), or use a program like LuLu or Little Snitch to block it from communicating with anything but your own selfhosted bitwarden_rs instance.
  - dastx 6y ago
    Do you have more information on this? A link maybe? EDIT: Never mind, found it - https://github.com/bitwarden/desktop/issues/552 https://github.com/bitwarden/desktop/issues/552. This isn't exactly an RCE. You can say the same about anything. By your logic Microsoft auto-updates are RCE. Same with pacman/apt-get/yum package managers. Same with pretty much anything else. I'm not saying they're not valid concerns, however, if you're this worried about all of these things, maybe cloud-based software isn't for you.
- hanniabu 6y ago
  Even if the takeaway from that conversation was that sha256 is good enough, it concerns me how the Bitwarden team handled that issue.
  - dastx 6y ago
    The few tickets I've been interested in, their answers have been along those lines. I've mentioned this before, but Bitwarden has been broken in Firefox's private mode, and to this day they're just blaming it Mozilla for deprecating some APIs due to privacy concerns. Mozilla has given a safer alternative, but they're refusing to fix it. Someone even raised a PR to fix it, but they had some feedback. The PR has since gone stale.
Macha 6y ago
Isn't this true for any service? We're just trusting that the bitwarden/server image or bitwarden.com won't do the same? Also this is only a risk if you use the provided Web vault. If you use the desktop, mobile or browser extension clients, it would require both Bitwarden LLC and dani garcia to conspire against you as the server doesn't control code those clients run and the API only provides it data in encrypted format. Finally, if you're that worried you can pin the container version by hash and only update when you are confident in the new version
- jamescontrol 6y ago
  Yes, but if a company does this, they are essentially killing themselves. They have presumably spent a lot of time creating a company, gain customers etc, whereas a single(?) maybe anonymous open source developer does not have that much to lose.
  - arkitaip 6y ago
    The single dev has their reputation and professional career to lose whereas companies can and regularly engage in all kinds of legal and or judo to avoid any responsibility towards users.
    - cromka 6y ago
      A single dev is an exploitation sitting duck. They can get hacked, they can be stoled from, they can be targeted by the NSA (or FSA, ...), they can make a small but fatal mistakes, and I doubt they conform to the level of policies that companies like FAANG impose on their security-critical teams. And all of the above are very good plausible deniability excuses, such that this single developer could, after all, be malicious and still not loose his reputation simply by claiming he got targeted by a 3rd party. Let that sink in: a single developer and their PC is a gatekeeper of everyone's safety.
  - alpaca128 6y ago
    > if a company does this, they are essentially killing themselves ...or they have to do it because of the NSA and weirdly 99% of users don't care or don't have the means to do anything about it. Companies aren't trustworthy, they are bigger targets but also targets with thicker armor. I just go with the offline route, KeepassXC runs well enough for me and is compatible with phones. I need to handle data sync myself but it's not like I change or add new passwords every day.
ianpurton 6y ago
You can avoid this by only storing part of your password in Bitwarden. The random part. Then when you log into somewhere add another secret (which you keep in your head) to the end of the password you stored in Bitwarden. Switch on 2FA everywhere you can. Sleep at night.
- CivBase 6y ago
  That's actually a cool idea for a password manager in general. After logging in, you input a "salt" value that is appended to the end of all your passwords. That value is never sent to the password server, so even if the server is compromised your associated accounts aren't.
  - jaegerma 6y ago
    There's actually a name for that: pepper Instead of a salt, which is random for each entry and has to be stored along the hash, one single pepper is added to each password before hashing and kept secret.
mnutt 6y ago
This is the use case that something like sandstorm.io tries to solve, by locking down system calls on the backend and (slowly but surely) CSP on the frontend. I don’t think BitWarden has been ported yet, though.
- foepys 6y ago
  Is sandstorm active again? A few years ago there was some news about the company behind it running out of money and abandoning the project if I remember correctly.
  - mnutt 6y ago
    It transitioned to a community project and is active again. The original contributors are still involved, just to a lesser degree.
Majromax 6y ago
With any password manager, encryption happens client-side. A malicious or compromised host could make off with your encrypted vault, but that would not by itself compromise passwords.
- colejohnson66 6y ago
  OP is arguing that the software could be changed to upload your encrypted version as usual, but also silently upload your unencrypted version. Either unintentionally (bug) or intentionally (tin foil hat saying NSA)
  - Majromax 6y ago
    That would require changes to the client as well, however, and as I understand it bitwarden_rs still uses the standard client-side Bitwarden addon/applications/apps.
chillfox 6y ago
You could always write your own password manager if you are that paranoid.
rbut 6y ago
The same could be said of every docker image on dockerhub, or any open source project on github, or any distro of linux.. I could keep going. Unless you review the source code of everything you use, and compile it yourself, there’s always that risk.
throwaway8581 6y ago
Because of the way bitwarden works, I think as long as the client is secure, compromise of the server is not a major concern except for data loss. Your vault is encrypted client-side. The real threat is that someone takes control of the bitwarden browser extension and pushes a malicious update.
- vbezhenar 6y ago
  > The real threat is that someone takes control of the bitwarden browser extension and pushes a malicious update. That's why I don't use any KeePass extensions. I just don't trust browser enough to be able to get any of my passwords. I'm thinking about writing my own extension which will communicate with KeePass in a way that suits me (basically: when I'm pressing button in browser, it'll popup KeePass window with search field filled with server domain. Then I can either auto-type password from KeePass or copy it to clipboard, either way I'm only using KeePass and browser extension have no way to get any information.
  - fencepost 6y ago
    I think there's a relevant xkcd about this, though technically it's about standards. I'd absolutely use KeePass for a long term storage password vault (with appropriately obscure reminders so I could recall the password), but the ecosystem of many unofficial free implementations for integration into browsers, phones (IIRC), etc. makes me twitch.
jillesvangurp 6y ago
You are in control here. It's like every other bit of software you run yourself: it's your problem to do it properly. 1) if you worry about people replacing the docker image you are using, build your own. It's not hard. Alternatively, use a specific version of the docker image by specifying the version or the hash (if you are really paranoid). Of course after you review the Dockerfile. Minimum at least glance through the Dockerfile. 2) bitwarden has import/export functionality (client side) so if your server disappears for whatever reason, you can still export your passwords from the client side. 3) if you don't trust the OSS code, audit it or at least look through it. That's the whole point of OSS. Build it from source if you must. File bugs. Look at the issue tracker. You can choose not to but if something happens it's your problem; not somebody else's problem. 4) The vault is encrypted and the server never handles or sees the decrypted content (see 3 to verify this). Other people's ability to break that encryption depends on you using a secure master password. 5) Or just pay Bitwarden to host passwords for you and rely on their terms of use, SLAs, support, good reputation, and what not. That's probably the best option if you want ass coverage for professional usage. Their pricing is very reasonable for small setups. And probably sharing passwords with a large group of users is just a spectacularly bad idea to begin with. A couple of key users, should cost you max 20/month. Not really worth dedicating devops time for self hosting unless you have a really good reason to. If you do, see 1-4.
- o-__-o 6y ago
  Bitwarden server phones home every install. In order to remove the phoning home bit, you must recompile the entire codebase. I wonder if this rust alternative makes that easier to remove...
- ClumsyPilot 6y ago
  "3) if you don't trust the OSS code, audit it or at least look through it. That's the whole point of OSS." Thats an outright fantasy, every day I rely on like 50 pieces of software written in 20 different languages and frameworks. They are updated multiple times a month. How many man hours would it take? 1000 a week? Proffesional developers couldn't find heartbleed for years, you really think anyone would notice a hidden backdoor in software like this withing a year?
sneak 6y ago
You self-host it. The data is going to your own server.
ryan29 6y ago
Isn't the same thing true for every password manager? What's stopping LastPass from pushing an update that steals all my passwords? What's stopping Chrome from auto-updating to a version that sends every password I enter to Google? It's not fair to single out just Bitwarden IMO.
paulryanrogers 6y ago
You could restrict its network access to only your LAN. Though in that case you could only sync within your LAN.
kayson 6y ago
I had the same concern. There's also the matter of supporting upstream development, which the maintainer does address in his readme. I ended up paying for a premium subscription of vanilla Bitwarden, which I self host. Sure it's overkill on resources and number of containers, but it's still insignificant. It seems slightly more safe to trust a company that depends on the software for revenue, if I'm going to use it without auditing the source. I've also e-mailed their support quite a few times, and they're great. It just doesn't feel right to me to do that while using a free custom backend to avoid the cost...

killingtime74 6y ago

Especially since bitwarden itself is already open source. This is a great learning project probably but not great for use

joaopms 6y ago
The greatest thing about this implementation is its simplicity. I actually deployed this server for my personal use because everything lives in one Docker image and not a lot of them like the official implementation. I do understand that the official implementation helps with scalability and more, I just don't need it.
Nullabillity 6y ago
The official Bitwarden server depends on MSSQL.

BiteCode_dev 6y ago

Same with basically any part of your infra. What prevents Postgres mainteners to just still all your DB ? Nginx mainteners to redirect your web traffic ? Ultimately, it boils down to a balance between trust in the author, the community or your own checking process.

novium 6y ago

If I'm not mistaken it should be mostly fine as long as you trust the desktop/phone versions of Bitwarden not to send off the (unhashed) key to the server Edit: Noting that there have been discussions about the default number of iterations. https://github.com/bitwarden/jslib/issues/52 https://github.com/bitwarden/jslib/issues/52

danmur 6y ago
The main problem I can see is entering your login in the web interface. I still use it though.
sneak 6y ago
Note also that the bitwarden desktop app has a remote code execution vulnerability that the developers refuse to fix, which means that the developers can, at any time, replace your local copy of the bitwarden desktop app with a different version that could steal all your passwords in exactly the manner you describe. You can patch the bitwarden client (and also take the opportunity to remove the spyware they have embedded in it, as well), or use a program like LuLu or Little Snitch to block it from communicating with anything but your own selfhosted bitwarden_rs instance.
- dastx 6y ago
  Do you have more information on this? A link maybe? EDIT: Never mind, found it - https://github.com/bitwarden/desktop/issues/552 https://github.com/bitwarden/desktop/issues/552. This isn't exactly an RCE. You can say the same about anything. By your logic Microsoft auto-updates are RCE. Same with pacman/apt-get/yum package managers. Same with pretty much anything else. I'm not saying they're not valid concerns, however, if you're this worried about all of these things, maybe cloud-based software isn't for you.
hanniabu 6y ago
Even if the takeaway from that conversation was that sha256 is good enough, it concerns me how the Bitwarden team handled that issue.
- dastx 6y ago
  The few tickets I've been interested in, their answers have been along those lines. I've mentioned this before, but Bitwarden has been broken in Firefox's private mode, and to this day they're just blaming it Mozilla for deprecating some APIs due to privacy concerns. Mozilla has given a safer alternative, but they're refusing to fix it. Someone even raised a PR to fix it, but they had some feedback. The PR has since gone stale.

Macha 6y ago

Isn't this true for any service? We're just trusting that the bitwarden/server image or bitwarden.com won't do the same? Also this is only a risk if you use the provided Web vault. If you use the desktop, mobile or browser extension clients, it would require both Bitwarden LLC and dani garcia to conspire against you as the server doesn't control code those clients run and the API only provides it data in encrypted format. Finally, if you're that worried you can pin the container version by hash and only update when you are confident in the new version

jamescontrol 6y ago
Yes, but if a company does this, they are essentially killing themselves. They have presumably spent a lot of time creating a company, gain customers etc, whereas a single(?) maybe anonymous open source developer does not have that much to lose.
- arkitaip 6y ago
  The single dev has their reputation and professional career to lose whereas companies can and regularly engage in all kinds of legal and or judo to avoid any responsibility towards users.
  - cromka 6y ago
    A single dev is an exploitation sitting duck. They can get hacked, they can be stoled from, they can be targeted by the NSA (or FSA, ...), they can make a small but fatal mistakes, and I doubt they conform to the level of policies that companies like FAANG impose on their security-critical teams. And all of the above are very good plausible deniability excuses, such that this single developer could, after all, be malicious and still not loose his reputation simply by claiming he got targeted by a 3rd party. Let that sink in: a single developer and their PC is a gatekeeper of everyone's safety.
- alpaca128 6y ago
  > if a company does this, they are essentially killing themselves ...or they have to do it because of the NSA and weirdly 99% of users don't care or don't have the means to do anything about it. Companies aren't trustworthy, they are bigger targets but also targets with thicker armor. I just go with the offline route, KeepassXC runs well enough for me and is compatible with phones. I need to handle data sync myself but it's not like I change or add new passwords every day.

ianpurton 6y ago

You can avoid this by only storing part of your password in Bitwarden. The random part. Then when you log into somewhere add another secret (which you keep in your head) to the end of the password you stored in Bitwarden. Switch on 2FA everywhere you can. Sleep at night.

CivBase 6y ago
That's actually a cool idea for a password manager in general. After logging in, you input a "salt" value that is appended to the end of all your passwords. That value is never sent to the password server, so even if the server is compromised your associated accounts aren't.
- jaegerma 6y ago
  There's actually a name for that: pepper Instead of a salt, which is random for each entry and has to be stored along the hash, one single pepper is added to each password before hashing and kept secret.

mnutt 6y ago

This is the use case that something like sandstorm.io tries to solve, by locking down system calls on the backend and (slowly but surely) CSP on the frontend. I don’t think BitWarden has been ported yet, though.

foepys 6y ago
Is sandstorm active again? A few years ago there was some news about the company behind it running out of money and abandoning the project if I remember correctly.
- mnutt 6y ago
  It transitioned to a community project and is active again. The original contributors are still involved, just to a lesser degree.

Majromax 6y ago

With any password manager, encryption happens client-side. A malicious or compromised host could make off with your encrypted vault, but that would not by itself compromise passwords.

colejohnson66 6y ago
OP is arguing that the software could be changed to upload your encrypted version as usual, but also silently upload your unencrypted version. Either unintentionally (bug) or intentionally (tin foil hat saying NSA)
- Majromax 6y ago
  That would require changes to the client as well, however, and as I understand it bitwarden_rs still uses the standard client-side Bitwarden addon/applications/apps.

chillfox 6y ago

You could always write your own password manager if you are that paranoid.

rbut 6y ago

The same could be said of every docker image on dockerhub, or any open source project on github, or any distro of linux.. I could keep going. Unless you review the source code of everything you use, and compile it yourself, there’s always that risk.

throwaway8581 6y ago

Because of the way bitwarden works, I think as long as the client is secure, compromise of the server is not a major concern except for data loss. Your vault is encrypted client-side. The real threat is that someone takes control of the bitwarden browser extension and pushes a malicious update.

vbezhenar 6y ago
> The real threat is that someone takes control of the bitwarden browser extension and pushes a malicious update. That's why I don't use any KeePass extensions. I just don't trust browser enough to be able to get any of my passwords. I'm thinking about writing my own extension which will communicate with KeePass in a way that suits me (basically: when I'm pressing button in browser, it'll popup KeePass window with search field filled with server domain. Then I can either auto-type password from KeePass or copy it to clipboard, either way I'm only using KeePass and browser extension have no way to get any information.
- fencepost 6y ago
  I think there's a relevant xkcd about this, though technically it's about standards. I'd absolutely use KeePass for a long term storage password vault (with appropriately obscure reminders so I could recall the password), but the ecosystem of many unofficial free implementations for integration into browsers, phones (IIRC), etc. makes me twitch.

jillesvangurp 6y ago

You are in control here. It's like every other bit of software you run yourself: it's your problem to do it properly. 1) if you worry about people replacing the docker image you are using, build your own. It's not hard. Alternatively, use a specific version of the docker image by specifying the version or the hash (if you are really paranoid). Of course after you review the Dockerfile. Minimum at least glance through the Dockerfile. 2) bitwarden has import/export functionality (client side) so if your server disappears for whatever reason, you can still export your passwords from the client side. 3) if you don't trust the OSS code, audit it or at least look through it. That's the whole point of OSS. Build it from source if you must. File bugs. Look at the issue tracker. You can choose not to but if something happens it's your problem; not somebody else's problem. 4) The vault is encrypted and the server never handles or sees the decrypted content (see 3 to verify this). Other people's ability to break that encryption depends on you using a secure master password. 5) Or just pay Bitwarden to host passwords for you and rely on their terms of use, SLAs, support, good reputation, and what not. That's probably the best option if you want ass coverage for professional usage. Their pricing is very reasonable for small setups. And probably sharing passwords with a large group of users is just a spectacularly bad idea to begin with. A couple of key users, should cost you max 20/month. Not really worth dedicating devops time for self hosting unless you have a really good reason to. If you do, see 1-4.

o-__-o 6y ago
Bitwarden server phones home every install. In order to remove the phoning home bit, you must recompile the entire codebase. I wonder if this rust alternative makes that easier to remove...
ClumsyPilot 6y ago
"3) if you don't trust the OSS code, audit it or at least look through it. That's the whole point of OSS." Thats an outright fantasy, every day I rely on like 50 pieces of software written in 20 different languages and frameworks. They are updated multiple times a month. How many man hours would it take? 1000 a week? Proffesional developers couldn't find heartbleed for years, you really think anyone would notice a hidden backdoor in software like this withing a year?

sneak 6y ago

You self-host it. The data is going to your own server.

ryan29 6y ago

Isn't the same thing true for every password manager? What's stopping LastPass from pushing an update that steals all my passwords? What's stopping Chrome from auto-updating to a version that sends every password I enter to Google? It's not fair to single out just Bitwarden IMO.

paulryanrogers 6y ago

You could restrict its network access to only your LAN. Though in that case you could only sync within your LAN.

kayson 6y ago

I had the same concern. There's also the matter of supporting upstream development, which the maintainer does address in his readme. I ended up paying for a premium subscription of vanilla Bitwarden, which I self host. Sure it's overkill on resources and number of containers, but it's still insignificant. It seems slightly more safe to trust a company that depends on the software for revenue, if I'm going to use it without auditing the source. I've also e-mailed their support quite a few times, and they're great. It just doesn't feel right to me to do that while using a free custom backend to avoid the cost...