Bitwarden_rs: Unofficial Bitwarden compatible server written in Rust(github.com)
github.com
Bitwarden_rs: Unofficial Bitwarden compatible server written in Rust
https://github.com/dani-garcia/bitwarden_rs
161 comments
Even if using this, remember to get a bitwarden license. It’s $10 for a whole year and keeps their dev afloat.
I use 1Password and still pay for a Bitwarden licence to support development of a viable open source alternative.
Just subscribed to Bitwarden. Was long overdue! Need to give back.
Please please please do this. I have plenty of issues with their prioritisation but at the end of the day, Bitwarden is extremely cheap, and is a great product. There is little to no reason to not pay that $10 a year.
Another satisfied user of `bitwarden_rs` here, and I can vouch for it. I migrated from LastPass and couldn't be more happier. The setup is pretty simple and I even managed to migrate it to a new server without any hassles. All the apps work flawlessly.
The peace of mind in having all your sensitive data under your control is totally worth it.
The peace of mind in having all your sensitive data under your control is totally worth it.
> The peace of mind in having all your sensitive data under your control is totally worth it.
I used to have some illusions that "if I self host, I am in control", and "if I don't connect my home infra to the internet, I am safe". Later I realized neither is true.
I can't trust all the consumer grade devices in my network, I don't trust a software just because it is open source. And I don't have time to keep up with all the security patches and do security auditing / vulnerability scan routinely...etc.
It is fine to self host hobby stuff for fun, but professionally managing sensitive data is a full time job.
I used to have some illusions that "if I self host, I am in control", and "if I don't connect my home infra to the internet, I am safe". Later I realized neither is true.
I can't trust all the consumer grade devices in my network, I don't trust a software just because it is open source. And I don't have time to keep up with all the security patches and do security auditing / vulnerability scan routinely...etc.
It is fine to self host hobby stuff for fun, but professionally managing sensitive data is a full time job.
Assuming that you're not a high profile target self-hosting does make it rather unlikely that you'll get pwned in this case.
An attacker can justify allocating a lot of resource to pwn bitwarden.com. If you manage to break into the vaults you're bound to find something juicy, just because of how large the target is.
Or you could decide to pwn me. Figure out where my bitwarden is hosted, what my config looks like, what mistakes I might have made setting it up, then maybe find a way in. Then it's just the start, since the passwords are encrypted on disk, so at best you have access to an encrypted sqlite database. Now you need to find a way to get me to leak my vault key. Maybe I sometimes use the web interface? Maybe not. Who knows.
After all of that you may realize that all of my passwords are either not super important or require some form of 2FA, therefore wasting your time.
But hey, you can log into my hacker news account!
Security through irrelevancy.
An attacker can justify allocating a lot of resource to pwn bitwarden.com. If you manage to break into the vaults you're bound to find something juicy, just because of how large the target is.
Or you could decide to pwn me. Figure out where my bitwarden is hosted, what my config looks like, what mistakes I might have made setting it up, then maybe find a way in. Then it's just the start, since the passwords are encrypted on disk, so at best you have access to an encrypted sqlite database. Now you need to find a way to get me to leak my vault key. Maybe I sometimes use the web interface? Maybe not. Who knows.
After all of that you may realize that all of my passwords are either not super important or require some form of 2FA, therefore wasting your time.
But hey, you can log into my hacker news account!
Security through irrelevancy.
Agreed, managing secure servers is a full time job.
The situation with Bitwarden is a bit different though. Secrets are encrypted on the clients, the server never sees decrypted data.
The situation with Bitwarden is a bit different though. Secrets are encrypted on the clients, the server never sees decrypted data.
Just set up backups, enable apt unattended upgrades for major security patches and forget the rest.
If you want to really get paranoid, pass it all through wireguard or ssh tunnels, but for bitwarden at least it's all client side encrypted anyways, you could probably run it on a very out of date system without issue.
If you want to really get paranoid, pass it all through wireguard or ssh tunnels, but for bitwarden at least it's all client side encrypted anyways, you could probably run it on a very out of date system without issue.
Sure. But do you constantly verify backups, check hard drive health and file corruptions, practice disaster recovery?
And these are just for the integrity of your _encrypted_ data. There are a lot more to do to fully secure your home infra in general. How do you secure your wireguard client key on the go? Do you monitor access logs? What about Guest Wi-Fi access, vlan separation...
I don't know if worrying about all these considered being paranoid. End of day it's about risk management, and personally, the benefits of selfhosting does not justify the effort I will need to put into maintaining it.
And these are just for the integrity of your _encrypted_ data. There are a lot more to do to fully secure your home infra in general. How do you secure your wireguard client key on the go? Do you monitor access logs? What about Guest Wi-Fi access, vlan separation...
I don't know if worrying about all these considered being paranoid. End of day it's about risk management, and personally, the benefits of selfhosting does not justify the effort I will need to put into maintaining it.
[deleted]
[deleted]
It’s not everything encrypted. The server sees what domains you have passwords for. So there is a lot of metadata visible on the server. You have to trust the server also if you use the web client because the web client is loaded from the server. It could leak all your data if the server is compromised and you log in via web.
> The server sees what domains you have passwords for.
The server does not see the domains you have passwords for. The following data are saved in plaintext:
- A list of "equivalent domains" (this starts out with a default list, but individuals can change this). This totally can be used to deduce which websites you have an account for, but that's not really enough information, as most websites will not have an entry here.
- Some metadata such as your email, master password hint
- Most of the boolean values (mfa enabled, email verified, premium)
- Custom field types (types only, field name, and value are both encrypted)
- Revision date
- Bunch of UUIDs
Here is what a single password entry looks like when retrieved from the /sync endpoint, which happens before decryption: https://pastebin.com/FLr19qiN
> You have to trust the server also if you use the web client because the web client is loaded from the server.
This is true! However, the android app, cli, and other clients do not get loaded from the server, thus, in theory, you can inspect the source of them, possibly compile it yourself, and use that. In those scenarios you do not have to trust the server.
The server does not see the domains you have passwords for. The following data are saved in plaintext:
- A list of "equivalent domains" (this starts out with a default list, but individuals can change this). This totally can be used to deduce which websites you have an account for, but that's not really enough information, as most websites will not have an entry here.
- Some metadata such as your email, master password hint
- Most of the boolean values (mfa enabled, email verified, premium)
- Custom field types (types only, field name, and value are both encrypted)
- Revision date
- Bunch of UUIDs
Here is what a single password entry looks like when retrieved from the /sync endpoint, which happens before decryption: https://pastebin.com/FLr19qiN
> You have to trust the server also if you use the web client because the web client is loaded from the server.
This is true! However, the android app, cli, and other clients do not get loaded from the server, thus, in theory, you can inspect the source of them, possibly compile it yourself, and use that. In those scenarios you do not have to trust the server.
I mean at the end of the day your data is encrypted before it leaves your device and unless someone breaks encryption you can display it on a banner ad on Times Square and it doesn't make a difference.
Personally I think hosting the server locally doesn't give much benefit because I'm more likely to screw things up than Bitwarden is on that front.
Personally I think hosting the server locally doesn't give much benefit because I'm more likely to screw things up than Bitwarden is on that front.
[deleted]
Personally, having my sensitive data under my own control (but internet facing) terrifies me. I know enough to know that there are risks, and yet wouldn't have a clue about how to make it secure.
My self-hosted bitwarden server is only accessible from the LAN. Since the full password database is cached locally on each client, you can use it to lookup existing passwords just fine without a connection to the server. Bitwarden does require a connection to the server to add passwords, as it isn't a distributed architecture, so this setup does prevent you from adding new passwords while you are out and about, but I don't have the need to do that often, and in the rare occasions when I do, I write them on scrap paper in my wallet till I get home.
For home use, and to a limited extent - when all your users are proficient - for corporate use, I really enjoy pass (https://www.passwordstore.org/). It has a decentralized architecture where passwords are synchronized via git, making it excel at situations where you need to generate or store secrets on the go. Unfortunately, the Windows client is not stellar, and the (unofficial?) Android app doesn't seem to have an option to encrypt secrets using more than one key, limiting its use for most teams.
I got really excited about pass for a bit and almost switched to it, until I realized I was likely increasing my attack surface because in addition to trusting the developer of pass, I also had to trust the developer of whatever other third-party clients I was using with it (such as the iOS client).
Switched to Bitwarden instead.
Switched to Bitwarden instead.
My concern about this is less about making it secure but keeping it secure. Zero-day vulnerabilities are a thing and you can never be 100% safe against those, so the next best thing is to have good monitoring in place so you get alerted when something nefarious is going on. This unfortunately requires 24/7 monitoring that's better left off to a dedicated team.
Just connect to it via wireguard or tailscale instead of exposing it to the entire internet.
Bingo.
If you're going to host services as home such as your password manager, set up a WireGuard VPN, you can use a Pi and it'll be perfectly sufficient, leave only the VPN open on the internet, VPN in from your phone, laptop, whatever for anything you need access to, and you don't need to rely on Nextcloud or Bitwarden having vulnerabilities discovered in them.
I was using Nextcloud previously for password sync because my password manager needs WebDAV, it was too much to maintain so I wrote a small server in Golang using the WebDAV library and it sits behind NGINX which handles the auth. I run Minio (S3 compatible) for syncing our family photos from our phones and Folder Sync app on Android. They both run on a VM and write out to a ZFS pool.
I have a Pi 3B+ running Raspbian mounted read-only as a WireGuard VPN for remote access, and we use the official WireGuard app. VPN is always on because we have fast, symmetric fibre, and we don't need to worry about trusting public networks.
If you're going to host services as home such as your password manager, set up a WireGuard VPN, you can use a Pi and it'll be perfectly sufficient, leave only the VPN open on the internet, VPN in from your phone, laptop, whatever for anything you need access to, and you don't need to rely on Nextcloud or Bitwarden having vulnerabilities discovered in them.
I was using Nextcloud previously for password sync because my password manager needs WebDAV, it was too much to maintain so I wrote a small server in Golang using the WebDAV library and it sits behind NGINX which handles the auth. I run Minio (S3 compatible) for syncing our family photos from our phones and Folder Sync app on Android. They both run on a VM and write out to a ZFS pool.
I have a Pi 3B+ running Raspbian mounted read-only as a WireGuard VPN for remote access, and we use the official WireGuard app. VPN is always on because we have fast, symmetric fibre, and we don't need to worry about trusting public networks.
Why would you mount read only, out of interest? How do you keep packages up to date? And what about logging? I'd want to be logging connection attempts.
To save the SD card mostly. I log to a ring buffer in RAM.
I've had my Raspberry Pis kill dozens of SD cards over the years, so read only can helas for updates, I manually remount read/write when I do maintenance and then remount read/only again when I'm done.
I've had my Raspberry Pis kill dozens of SD cards over the years, so read only can helas for updates, I manually remount read/write when I do maintenance and then remount read/only again when I'm done.
Thanks. I might have a look into doing it for mine, since that seems to make sense. I guess like you said you can just mount the fs rw, and then chroot in to run updates.
No need for chroot, I just say in when I'm on the LAN, remount / and /boot r/w, run the updates and reboot (boots any new kernel and switches back to r/o).
probably to save the SD card
I would set it up locally on raspberrypi with PiVPN and only allow specific IP (bitwarden IP) to be accessible via that VPN connection. Also you will need self-signed cert installed on the devices where you want to access bitwarden if you dont have a public domain.
I had to same thought so I put behind a VPN. a little less convenient. but WAY more secure
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?
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?
Especially since bitwarden itself is already open source. This is a great learning project probably but not great for use
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.
The official Bitwarden server depends on MSSQL.
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.
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.
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
Edit: Noting that there have been discussions about the default number of iterations. https://github.com/bitwarden/jslib/issues/52
Even if the takeaway from that conversation was that sha256 is good enough, it concerns me how the Bitwarden team handled that issue.
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.
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.
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.
Do you have more information on this? A link maybe?
EDIT: Never mind, found it - 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.
EDIT: Never mind, found it - 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.
The main problem I can see is entering your login in the web interface. I still use it though.
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
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
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.
> 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.
...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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
It transitioned to a community project and is active again. The original contributors are still involved, just to a lesser degree.
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.
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)
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.
You could always write your own password manager if you are that paranoid.
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.
Unless you review the source code of everything you use, and compile it yourself, there’s always that risk.
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.
The real threat is that someone takes control of the bitwarden browser extension and pushes a malicious update.
> 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.
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.
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.
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.
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.
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.
"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?
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?
The keyword in that sentence is trust. Either trust or check. Your choice.
Most people choose to trust certain software providers based on their reputation. But if you have serious doubts and you don't check, that would be your problem.
Whining about an open source project maybe being insecure basically means either check it or don't use it. Nobody is twisting your arm to risk your passwords on some wonky self hosted setup. Your problem if it blows up in your face. That's also what it spells out in a typical OSS license (that would be the section talking about limited liability). That's another thing people tend to not check that they probably should pay some attention to. Using the software means accepting that it's your responsibility.
If like most you are unable to make a sound judgment on this front; consider paying a service provider providing you a service. That would be Bitwarden in this case. They kindly provide a free version even. Easy choice IMHO.
Heart-bleed slipped through the cracks for a while and then certain software providers lived up to their reputation by providing fixes in a timely fashion. And certain others messed up by not doing that. I care more about how developers act when something like this happens than the fact that it happens.
OSS software providers are no different than other providers when it comes to trust. Except you have the option of looking at their code. Lots of people doing that builds trust. I tend to look at things like number of stars, commit frequency, and other things when deciding to use a random Github thing. When it comes to software that is safety critical, I prefer the scrutiny of an active community of developers. That just increases my level of trust.
IMHO Bitwarden's trustworthiness just went up by virtue of there being multiple implementations of the thing and apparently a growing community of users and developers depending on these things. I'm already using it and vastly prefer this over some closed source solution with opaque development processes. I probably would not self host but it is nice to have that option available.
Most people choose to trust certain software providers based on their reputation. But if you have serious doubts and you don't check, that would be your problem.
Whining about an open source project maybe being insecure basically means either check it or don't use it. Nobody is twisting your arm to risk your passwords on some wonky self hosted setup. Your problem if it blows up in your face. That's also what it spells out in a typical OSS license (that would be the section talking about limited liability). That's another thing people tend to not check that they probably should pay some attention to. Using the software means accepting that it's your responsibility.
If like most you are unable to make a sound judgment on this front; consider paying a service provider providing you a service. That would be Bitwarden in this case. They kindly provide a free version even. Easy choice IMHO.
Heart-bleed slipped through the cracks for a while and then certain software providers lived up to their reputation by providing fixes in a timely fashion. And certain others messed up by not doing that. I care more about how developers act when something like this happens than the fact that it happens.
OSS software providers are no different than other providers when it comes to trust. Except you have the option of looking at their code. Lots of people doing that builds trust. I tend to look at things like number of stars, commit frequency, and other things when deciding to use a random Github thing. When it comes to software that is safety critical, I prefer the scrutiny of an active community of developers. That just increases my level of trust.
IMHO Bitwarden's trustworthiness just went up by virtue of there being multiple implementations of the thing and apparently a growing community of users and developers depending on these things. I'm already using it and vastly prefer this over some closed source solution with opaque development processes. I probably would not self host but it is nice to have that option available.
Who is whining? OP even said they love the project. They're just asking a question.
I am not taking a stab at bitwarden or OSS, but this talking point about trust is total tripe.
It is a choice to obey the law of gravity? Because Its physically impossible for one person to check all security critical code they come in contact with even if they know every single programming language and have a Phd in cryptography. So stop with the accusatory language about 'whining' and pontification about choice.
It is a choice to obey the law of gravity? Because Its physically impossible for one person to check all security critical code they come in contact with even if they know every single programming language and have a Phd in cryptography. So stop with the accusatory language about 'whining' and pontification about choice.
With the official Bitwarden repos, this is solved by having reputable teams periodically run security audits. Sadly, it's unlikely this Rust implementation will be audited any time soon.
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...
4) this not 100% true. To get someone’s passwords you just have to compromise their bitwarden_rs to include a malicious web client that sends the master password to the attacker if the user logs in. This is a different story of course when the web client is never used. Then it is impossible to get the passwords because it’s encrypted at client side.
You self-host it. The data is going to your own server.
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.
It's not fair to single out just Bitwarden IMO.
You could restrict its network access to only your LAN. Though in that case you could only sync within your LAN.
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...
I set it up in a couple of minutes using Docker-compose with Traefik. I love that Bitwarden has clients and plugins everywhere (FF and iOS being most relevant to me) and I can self-host. The sweetspot for me. I have had too many conflicts with my KeepassXC database on Nextcloud in the past, time for a solution with integrated sync.
Btw the "custom server" setting is a bit hidden, it is behind the cogwheel in the upper left in most cases.
Btw the "custom server" setting is a bit hidden, it is behind the cogwheel in the upper left in most cases.
I switched to Bitwarden when LastPass changed their policy for multi-device users. I'm happy to say the transition was completely painless.
I switched over when I realised the Lastpass browser integration was chewing up CPU and significantly slowing down my browsing experience.
Even their CSV import worked flawlessly and my CSV export from Lastpass looked like a train wreck to parse but everything is present and correct in bitwarden.
Did you consider KeePass or one of the variants?
I'm using KeePass. On Linux, windows and android and Google drive to sync the database.
it is a hassle.
The graphics look terrible. And most of the times the keeweb plugin doesn't really work on Firefox and I have to copy paste the password.
But I have been using it for a long time now and got used to it.
The best thing about it is the plugin system.
I would not suggest it, I think bit warden does all of this and is a lot more user friendly.
I use KeePass on one of my projects and I find Bitwarden much better than KeePass. We're moving to Bitwarden soon to keep it seamless across teams.
I do use KeePass for work, since we're not authorized to put passwords on the cloud, but device synchronization and browser auto fill is a pain.
For personal, Bitwarden is much better. Browser plugins just work, android auto fill just works, passwords synchronized across devices, support for auto filling payment information. 2FA support.
For personal, Bitwarden is much better. Browser plugins just work, android auto fill just works, passwords synchronized across devices, support for auto filling payment information. 2FA support.
Did you try KeePassXC? It's much more actively developed and runs circles around the original KeePass:
— it's a native application (starts instantly on less powerful machines)
— can check your accounts against haveibeenpwnd.com database
— has full browser integration which works flawlessly IME
— can store SSH keys and work as an SSH agent
https://keepassxc.org/
edit: it does not support synchronization, I misremembered. Sorry.
— it's a native application (starts instantly on less powerful machines)
— can check your accounts against haveibeenpwnd.com database
— has full browser integration which works flawlessly IME
— can store SSH keys and work as an SSH agent
https://keepassxc.org/
edit: it does not support synchronization, I misremembered. Sorry.
Same here. I switched from LastPass and I really like the UX more than LastPass. It is less intrusive and feels more polished and snappier.
The UX is actually kind of bad. I think it is electron-based, the menus are far from a work of art, and the folder management seems very primitive.
But that said, it is by far the best product despite this.
But that said, it is by far the best product despite this.
What do you mean Electron based? There's no such thing as an "Electron-based UX".
Bitwarden clients have the same UX across OSes and platforms ( browser extension, mobile app, thick client". The thick clients are indeed Electron based.
Bitwarden clients have the same UX across OSes and platforms ( browser extension, mobile app, thick client". The thick clients are indeed Electron based.
I think what was being said is the fact an app uses Electron rather than being native can diminish UX. I think it was clear enough from the post, at least from context.
I'm actually a bit confused by 'the same UX across OSes'. What does this mean? The mobile UI is completely different to the desktop apps and web app.
I'm actually a bit confused by 'the same UX across OSes'. What does this mean? The mobile UI is completely different to the desktop apps and web app.
I was about to complain about how their mobile UI made me click a tiny button in the top right instead of using the massive button that did something entirely useless, went to check what the button actually was and found out they've now fixed it.
Props to the Bitwarden guys for fixing the only thing that really bothered me with the UI.
Props to the Bitwarden guys for fixing the only thing that really bothered me with the UI.
My company used to use the unmaintained "CorporateVault", but switched to Bitwarden_rs after Flash (which CorporteVault used for copying to the clipboard) was deprecated. Bitwarden_rs was chosen because it had a relatively painless install compared to pretty much everything else I looked at, requiring only one Docker container. It's not bad.
You give in trust your company’s passwords to a random dude’s open source project that was never audited professionally. Seems a very risky thing to do.
The only thing you have to trust on a BitWarden server is the Javascript client that it serves you, and using that is entirely optional as you can just use other clients. The server could be explicitly malicious and still safe to use.
bitwarden_rs bundles the upstream JS in its default containers, so it's the same code that you'd be running from bitwarden.com
bitwarden_rs bundles the upstream JS in its default containers, so it's the same code that you'd be running from bitwarden.com
Both server impls end up with a bunch of binary crap in the end.
You don’t even need docker if you build from source
Maybe you didn't get the whole "I picked it because it was easy to install" part. Building software from source is pretty much the exact opposite of that.
Rust is designed to be built from source, and the development toolchain is light enough to keep on a VPS if that's your bag. If you have Cargo installed, compiling and installing from source is easier than using NPM.
> and the development toolchain is light enough to keep on a VPS
Or, you know, in a Docker container...
I build pretty much everything that's not C/C++ and/or Go using a Docker container now.
When you're working in a team, it's also an amazing way to share the build environment
Or, you know, in a Docker container...
I build pretty much everything that's not C/C++ and/or Go using a Docker container now.
When you're working in a team, it's also an amazing way to share the build environment
I couldn't care less about Rust. The fact that this project used it is irrelevant to me and I have no desire to setup a Rust build env.
[deleted]
It really depends. Go and Rust softwares are generally easy to build from source
I was trying out a bunch of different similar products, I was not going to set up a build environment just to test software. I immediately disqualified anything that required I build it from source.
Of the ones that didn't, very few had working install documentation and I wasn't going to fix it for them just to try out their product. I did open issues on their trackers about it for them, not that they cared since nothing has been done.
Bitwarden_rs was the one that had working install documentation that didn't require a build environment. It met our requirements in testing, so I deployed it to production.
Of the ones that didn't, very few had working install documentation and I wasn't going to fix it for them just to try out their product. I did open issues on their trackers about it for them, not that they cared since nothing has been done.
Bitwarden_rs was the one that had working install documentation that didn't require a build environment. It met our requirements in testing, so I deployed it to production.
Yes but coming from a go or rust neophyte to trusting that you've installed correctly from source is probably a higher bar than knowing that you've run a container correctly.
Lmfao, you assume that docker is easy to install
Docker was an apt install, it wasn't exactly what I would call difficult.
It's not?
I switched to using this because keepass didn’t have a good way of syncing its database with iOS devices, and the official bitwarden server has too many moving parts (including MS-SQL with no support for open source databases??) - aside from missing ssh-agent support, I’m loving all of it :)
SQL isn't as portable as people would like. Especially when you're trying to stay high performance as you're dealing with millions of customers. Once you start building for a specific SQL server, it hard to switch to another variant.
[deleted]
I use it and it's great. Best way to self host it imo.
anyone moved from Keepass(XC) to bitwarden?
I do see advantage of being cloud based as a way to avoid database conflicts (in my case 3 windows machines + mobile), but I wonder what can surprise me here. Is bitwarden's browser integration similar to KeepassXC (Keepass helper + KeepasXC-browser)?
I do see advantage of being cloud based as a way to avoid database conflicts (in my case 3 windows machines + mobile), but I wonder what can surprise me here. Is bitwarden's browser integration similar to KeepassXC (Keepass helper + KeepasXC-browser)?
I love Bitwarden. It's a great piece of software and it's reasonably priced. We use it at my place of work (I pushed to install and use Bitwarden on the company level). I also tried the Bitwarden_RS, it does the same work however it's not suited for company use as it lacks the feature to create groups. There's an open issue that provides a workaround, however that workaround proved to be unusable. I tried to reach out to maintainers to see whether the feature could be implemented and paid for their effort but.. let's just say the answer was "No.".
Long story short - we use official Bitwarden and are paying for it and couldn't be happier. Bitwarden_RS looks like a cool toy, but I can't see any reason why anyone would run it. It's good for personal passwords, but Bitwarden itself offers free service so there's no need to venture down the self-hosted road.
Long story short - we use official Bitwarden and are paying for it and couldn't be happier. Bitwarden_RS looks like a cool toy, but I can't see any reason why anyone would run it. It's good for personal passwords, but Bitwarden itself offers free service so there's no need to venture down the self-hosted road.
I chose to use bitwarden_rs because the official server is huge, and deploying it seemed like a massive pain.
Before installing the rust version I actually went through the code to check that it wasn't doing anything untoward; it wasn't a very thorough review, but it took a couple hours. Given the fact that you don't actually need to trust a Bitwarden server, I'm not too concerned about using an "unofficial" implementation.
Before installing the rust version I actually went through the code to check that it wasn't doing anything untoward; it wasn't a very thorough review, but it took a couple hours. Given the fact that you don't actually need to trust a Bitwarden server, I'm not too concerned about using an "unofficial" implementation.
I run bitwarden_rs for exactly the reason you stated, for personal passwords.
It took a few seconds to add to my portainer (docker) server and now I host my vault and keep it safe within my LAN.
It took a few seconds to add to my portainer (docker) server and now I host my vault and keep it safe within my LAN.
I ran bitwarden_rs for a bit on a digital ocean node, but ultimately decided to buy a premium membership because it was less than $5/mo and I think that they will do a better job securing the system and keeping things up to date than I would in my spare time.
> It's good for personal passwords, but Bitwarden itself offers free service so there's no need to venture down the self-hosted road.
It's a trust issue. I don't trust my passwords on someone else's server. I don't trust free services to remain free forever. I don't trust paid services to not increase the fees 4x over a few years.
The alternative to bitwardenrs or bitwarden/server is not bitwarden.com for me given the areas I'm concerned with, it's going back to KeePass + Syncthing.
I think the reticence to provide the group features in bitwarden_rs may come from being unwilling to too blatantly step on the toes of Bitwarden LLC by producing a $0 drop in alternative to their paid service. bitwarden_rs is open source and bitwarden/server is _mostly_ open source (Some SSO related features are not), so it seems worthwhile to get along and not need to fork the ecosystem.
It's a trust issue. I don't trust my passwords on someone else's server. I don't trust free services to remain free forever. I don't trust paid services to not increase the fees 4x over a few years.
The alternative to bitwardenrs or bitwarden/server is not bitwarden.com for me given the areas I'm concerned with, it's going back to KeePass + Syncthing.
I think the reticence to provide the group features in bitwarden_rs may come from being unwilling to too blatantly step on the toes of Bitwarden LLC by producing a $0 drop in alternative to their paid service. bitwarden_rs is open source and bitwarden/server is _mostly_ open source (Some SSO related features are not), so it seems worthwhile to get along and not need to fork the ecosystem.
> It's a trust issue. I don't trust my passwords on someone else's server.
They don't have your decryption key, therefore they save encrypted blobs and have no means to obtain your password. This takes care of trust issue - it simply is not an issue and never will be.
Even if malicious employee does something out of the ordinary or "hacker" gets the database, they still have the impossible task of breaking the encryption (which for all intents and purposes is impossible as of right now).
This returns us back to my starting point - there's *no objective* reason to use bitwarden_rs, apart from curiosity and/or convenience. I'm not saying it SHOULD not be used. We are all free to make choices as we see fit and don't need to justify them, however the reasons you listed are not reasons at all because the concerns you have don't exist.
They don't have your decryption key, therefore they save encrypted blobs and have no means to obtain your password. This takes care of trust issue - it simply is not an issue and never will be.
Even if malicious employee does something out of the ordinary or "hacker" gets the database, they still have the impossible task of breaking the encryption (which for all intents and purposes is impossible as of right now).
This returns us back to my starting point - there's *no objective* reason to use bitwarden_rs, apart from curiosity and/or convenience. I'm not saying it SHOULD not be used. We are all free to make choices as we see fit and don't need to justify them, however the reasons you listed are not reasons at all because the concerns you have don't exist.
> however the reasons you listed are not reasons at all because the concerns you have don't exist.
You've only attempted to address 1 of 3, and the other reply indicates that there is absolutely attack vectors from bitwarden.com if bitwarden LLC wanted to, was forced to, or was compromised.
You've only attempted to address 1 of 3, and the other reply indicates that there is absolutely attack vectors from bitwarden.com if bitwarden LLC wanted to, was forced to, or was compromised.
> ...therefore they save encrypted blobs and have no means to obtain your password.
Sure they do. The web vault. Plenty of functionality isn't available anywhere else.
Sure they do. The web vault. Plenty of functionality isn't available anywhere else.
Agreed, especially with how easy bitwarden_rs is to deploy (I wrote a three-line file and deployed it to my Dokku server and that was it).
I run bitwarden_rs for my own passwords because I want to run my own stuff for anything like passwords. (Previously I used KeePassX, and my biggest issue with it was that it was mostly tied to one device, depending on whatever file-based sync you might set up, and I never did—barring backups—so it was only ever on my main laptop, not on any secondary laptop or phone unless I jumped through some hoops to use one of the backups.)
I don’t run the official Bitwarden server because its system requirements are much too high for my liking.
Meanwhile, bitwarden_rs uses ~24MB disk space, ~24MB RAM, and <0.03% CPU on my single-core Vultr box.
Oh yeah, one other practical reason I couldn’t/wouldn’t go with bitwarden.com’s free plan: I’ve got a few TOTP things in my vault, gotta pay for that.
I don’t run the official Bitwarden server because its system requirements are much too high for my liking.
Meanwhile, bitwarden_rs uses ~24MB disk space, ~24MB RAM, and <0.03% CPU on my single-core Vultr box.
Oh yeah, one other practical reason I couldn’t/wouldn’t go with bitwarden.com’s free plan: I’ve got a few TOTP things in my vault, gotta pay for that.
a simple rsync client that could extract passwords from the data would be nice
Why not just get down to the basics write it yourself, like use rsync | pgp/openssl aes | rg/grep, isn't that what you want basically?
Bitwarden has a CLI tool which is pretty good.
what I mean is that why do you need bitwarden at all?
This is going to sound sketchy because any software project involving cryptography is automatically sketchy unless it has hit some nebulous and ill-defined 'accepted' status, but I've been working on a CLI tool to manage my passwords for a while that I'm honestly not ready to share, but the architecture so far is very simple:
Each 'service block' is an encrypted file consisting of service name, service password (autogenerated), kv-store, some metadata for regenerating new passwords. The key to each service block is the hash of a primary password. The name of the 'service block' file is the hash of the service name. All of the service blocks are stored together in a folder that can be rsynced wherever.
My worry is obviously in the crypto. While I'm not doing anything too fancy I worry about timing attacks because an attacker will have the full encrypted block so the system is vulnerable to that sort of thing.
Each 'service block' is an encrypted file consisting of service name, service password (autogenerated), kv-store, some metadata for regenerating new passwords. The key to each service block is the hash of a primary password. The name of the 'service block' file is the hash of the service name. All of the service blocks are stored together in a folder that can be rsynced wherever.
My worry is obviously in the crypto. While I'm not doing anything too fancy I worry about timing attacks because an attacker will have the full encrypted block so the system is vulnerable to that sort of thing.
There are many other options for password management that are very similar.
Writing them down in a notebook next to your computer. A homebrew system like e-mailing GPG-encrypted files to yourself. Your browser's built in password saving and sync features. A password-protected Excel spreadsheet on your dropbox.
Compared to a notebook, I can access my passwords from my phone if the need arises, and they're encrypted and backed up should I lose my phone.
Compared to a homebrew system, someone else has done the work and made a cross-platform system with nice browser extensions, sensible defaults, and so on.
Compared to my browser's sync features, there's peace of mind because it's not a free feature from a corporation famous for nonexistent customer service and sketchy tracking practices.
Compared to dropbox, the price is trivial (as they only have to store a few kilobytes of data) and it's focused on security.
Writing them down in a notebook next to your computer. A homebrew system like e-mailing GPG-encrypted files to yourself. Your browser's built in password saving and sync features. A password-protected Excel spreadsheet on your dropbox.
Compared to a notebook, I can access my passwords from my phone if the need arises, and they're encrypted and backed up should I lose my phone.
Compared to a homebrew system, someone else has done the work and made a cross-platform system with nice browser extensions, sensible defaults, and so on.
Compared to my browser's sync features, there's peace of mind because it's not a free feature from a corporation famous for nonexistent customer service and sketchy tracking practices.
Compared to dropbox, the price is trivial (as they only have to store a few kilobytes of data) and it's focused on security.
Ensure that the data is stored securely, integrate with the various password-manager hooks of OS and browsers, generate passwords, …
Something about running your own password manager server seems very risky to me.
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).
[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).
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
I can assume you are referring to... the automatic updater? https://github.com/bitwarden/desktop/issues/552
What other options would there even be for updates? That bug report describes every updater I've ever seen.
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.
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.
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.
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.
This is NOT a RCE. Would you like me to list all of the software that does this exact thing? Chrome, Brave, Discord are some of the biggest. Nearly all electron based apps that autoupdate.
You forgot the Creative Cloud, iOS (autoupdates on by default), and the Play Store.
Those are RCE vulnerabilities, as well. Platform vendors love being able to execute whatever they like on the advertising consumption devices that don't belong to them.
Just because it feels like a different thing because it's the vendor (only in theory - TAO would like to have a word with you) doesn't make it any less a vulnerability, or any less an RCE by the strict definition. Installing the client is equivalent to installing a RAT onto your machine: it can be remotely controlled to execute any code or tools the other end wants.
Those are RCE vulnerabilities, as well. Platform vendors love being able to execute whatever they like on the advertising consumption devices that don't belong to them.
Just because it feels like a different thing because it's the vendor (only in theory - TAO would like to have a word with you) doesn't make it any less a vulnerability, or any less an RCE by the strict definition. Installing the client is equivalent to installing a RAT onto your machine: it can be remotely controlled to execute any code or tools the other end wants.
Thats not how the definition of RCE works. Under your silly logic every piece of server/client software is a "RAT". To be honest I feel like you're trying to speed run ur way to the Attrition Hall of Charlatans
Why don't you just disable the updater then?
https://github.com/bitwarden/desktop/issues/552#issuecomment...
https://github.com/bitwarden/desktop/issues/552#issuecomment...
There's no good way to set env vars for GUI apps on macOS. I just run a private fork that patches out all of their hostnames.
Any more information on your claims? This is the first time I hear of this...
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.
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.
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).
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).
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.
I get where you are coming from, but you clinking "update" in stead of the dev does not guarantee the safety of the update.
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.
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.
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.
If the goal is to prevent the most volume of exploitation, autoupdaters clearly win.
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.
polote(4)