Vaultwarden: Unofficial Bitwarden compatible server written in Rust
github.com
github.com
+ I really enjoy this era of self-hosted tools.
vaultwarden, or bitwarden-rs as it used to be called, have been working flawlessly for years on my side, updates always work just as expected, and it supports a lot of organizational features too.
But I felt like it was better to trust bitwarden’s cloud for professional stuff, just for the reliability.
My setup was based on their Docker images, and thinking it was the safest option I had set up Watchtower to automatically update to the latest image nightly to get the latest security patches. But then I discovered that the bitwarden-rs image had not been updated for _months_ because of the rename.
So basically I was hosting my whole password database in this, and I had suddenly lost security updates without realizing.
Btw, I'm not blaming neither Vaultwarden or Bitwarden. But if you're going to self-host something this security critical, just be sure that you definitely monitor it _manually_ to make sure you're not on some unpatched vulnerable version some months down the line.
Better to put everything in git and run your own renovate bot which will create PRs for you to review and also pull in the changelogs to the PR itself so you can check for breaking changes.
E.g. you deploy with DATABASE_URL=x
This becomes DATABASE_URL=x PYTHON=3.0.0
You did not set the Python one, the image did via ENV.
Now a new version comes out with PYTHON=3.1.0.
Watchtower doesn't know which ENVs you set and which ones came from the container as docker inspect exposes them in the same way.
So now Watchtower deploys the new version (which only has Python 3.1.0) with DATABASE_URL=x PYTHON=3.0.0.
And stuff stops working.
I use an ansible playbook which maintains the only ENV vars that need to survive an update.
Seems like it's very close. The recent updates on the past couple of days sounds very positive, home-stretch & all that.
What an effort!
Eventually, I ended up using Pass though, since I prefer terminal. Pass doesn’t have any database to break: it’s just gpg and git. With Yubikey, every password needs a touch.
There is a good mobile app for Pass though (I don’t use it). I try to separate the systems, and not to share as much as possible. Otherwise, Vaultwarden would quickly sync, and is reliable.
Pass with Yubikey is more secure than other password managers in my opinion: You decrypt the password for a site and other passwords are not exposed. With other password managers, the whole vault has to be decrypted.
There is a CLI, but like KeepassXC I’m not sure it’s per password. All passwords seem to be encrypted with the same master key. Note that since the encryption is symmetric, for encryption you still need to expose the master key.
I'd really love to try Vaultwarden as Bitwarden is pretty heavy on the little server it runs on
I think there's a third party tool that will dump everything.
Genuine question, in what scenario is the self hosting setup and maintenance worth it?
Your family won't be able to add new passwords, but they can export them at their leisure.
I do find the Firefox browser extension sometimes logs me out (this is separate to the vault lock timer which just asks for a password, the extension basically resets to asking for a user ID)
I'd say if it is a problem being fixed, it is not across the board yet.
Offline access in Bitwarden client only works for 30 days. : https://bitwarden.com/blog/configuring-bitwarden-clients-for....
This was one of the main reasons why I switched from self-hosted Vaultwarden to KeePass.
I’ve made a pact with a similarly techy friend of mine that should something happen to either of us the other will step in and maintain in the short term, transition to something more hands off in the long term. But I still pay for Bitwarden for that extra level of reassurance.
I've got Vaultwarden setup on one of my servers via Docker and I've got nightly backups of my vault to Dropbox via docker-volume-backup[0], which works wonderfully.
I personally choose to self-host because I already have the infrastructure for it, so might as well put it to good use.
Maybe if you're a huge org with a dedicated security team and so on, which could easily handle managing such service. I guess at a certain point it would bring cost savings at a scale in comparison to using Bitwarden, where it costs per team member or seat. Inhouse team has fixed costs in comparison.
Of course for smaller orgs or individuals there is little sense in hosting security software yourself. No way you're going to have enough time to manage the service and keep it secure, which is where almost all of such software's value is derived from.
The official server needs a lot of different services and resources, so it’s not suitable for smaller deployments.
Personal use. Using this avoids the potential of a bitwarden hack (see: LastPass) leaking out all your passwords. You are much less likely a target than a central server like bitwarden.
For me more than anything else, it means that even if Bitwarden goes under then there always be a version I can run myself, at least until the situation becomes untenable and I find a new password manager.
A form of disaster mitigation, if you want to think of it that way.
I did this with Scaleway, took 2-3 minutes to setup.
So as a hobbyist, when you have a handful of services you are self hosting, adding another one makes more sense.
And running 5+ different services is probably cheaper in the long term.
If you have the skills, initial setup takes minutes. If you lack the skills, it is a good idea to invest your time into learning those skills, they are very handy if you work in the software development field. It certainly has become very useful at work for me.
For me personally updates, backups, restores and deployments of containers are mostly automated and on average I don't spend more than an hour per month to maintain all of the already running services.
Also I don't see the time as being wasted, since I enjoy doing it. Watching TV or playing video games is probably worse and I still do that as well, same as many other people.
But self-hosting scales horizontally. If you already run one service that uses postgres or MySQL, the next service often won't add much of a burden.
For a lot of people, yeah, at present it makes no sense to get started. But the ability to get inertia, to carry the effort, can grow and grow into something really fierce. And even better, there are such good references & starting places out there today. Onedr0p's home-ops is a beautiful example (one among many) of investing hard on really good tools up front, so that the incrental cost of adding and managing new things is fantastically low. Years ago we would have to diy much of this, but today onedr0p can use well known community tools like Kubernetes, Flux ci/CD, gitops, and helm to get it done, to have other smart making the tools of self-hosting better for him. He's still the self hosting, but there's a sizable % of the engineering talent of the world helping to make his self hosting better & easier. That's pretty novel, and pretty excellent imo. https://github.com/onedr0p/home-ops
Here is one scenario where self hosted could be more secure. If Bitwarden is required by a party, they can push bad code to a particular IP address and grab the master key. Not with self hosted, like that.
Perhaps there is also no limit to the total vault attachment storage (there is per password limit at 500 MB), and other limits that might be in Bitwarden.
I think Rust is a great language, but I think it shines in contexts where you'd previously have used C or C++. Web apps aren't really one of those contexts, unless they're microservices with extreme performance requirements, and this isn't the case here. Why would one choose to write something like this in Rust over easier-to-write languages like Go?
Can't speak for the author, but I'd choose Rust over Go/Java/Python for such projects for following reason:
* Rust is a more pleasant language to work with, i.e. Sum type, pattern matching, and Drop trait closing resources/cancelling tasks.
* Type system is much more robust than Go and Java, resulting in better quality code with less requirement of unit tests.
* I don't care about performance much (for personal projects), but a free performance is always a win.
I think people already exposed to Hindley-Milner will find Rust far more tolerable and productive than Go.
Last I checked the local cache is gone after so many days, leaving you without your credentials.
A combination of local password manager and a file sync service of your preference seems a good option as well.
I'm somewhat less crazy-eyes about the importance of backing things up properly than some people on HN can get. A lot of personal content I can honestly just accept the risk of losing it. However, if there is an exception to that, your password vault is it. It is possible to get yourself into a situation where you are completely locked out of things and the more systems go to harder authentication that you can't even store in your head like TOTP and hardware tokens the easier it gets to be in a world where if you lose your vault you can't recover because you can't even log in to the email account you'd use to recover.
If you care enough to run a personal Vaultwarden, you should care enough to back it up too. If you don't want to back it up, you probably shouldn't run it locally and just use the service.
Exactly right. I have a script that briefly stops my Vaultwarden container and creates a .tgz of the contents of the data volume before restarting the container. The .tgz file gets copied off-site so I always have an accessible backup should my main host disappear.So even in my modest environment, you're asking me to write special support for backing up a MySQL DB, the SQLite DB used by vaultwarden, and I don't even know what that mess in the Plex directory is. Or I can just write the same "shut it down, back it up, bring it back up" for every service, regardless of what database it currently has, what it may change to in the future, or what other databases some other service might decide it wants. It's an easy choice.
Moreover, Vaultwarden and Proton Pass make using Passkeys and sharing credentials with org or family members trivial (arguably Proton Pass even more so than Vaultwarden).
- Create threat models that identify weaknesses in the design of your self-hosted setup.
- Harden the OS with things like MAC, and harden the container with dropped privs, read-only root filesystem, and outbound network filtering.
- Deploy an intrusion detection system to know if you've been compromised.
- Perform all OS and app patching automatically, or regularly without fail.
- Follow CVE feeds in case a zero day needs to be fixed before the next patch window.
- Arrange for an expert to perform regular penetration tests.
- Deploy a tool that detects and alerts on things like firewall misconfigurations.
- Regularly test your backup and recovery methods, since if you also store 2FA codes and backup codes in there, you could be permanently locked out of your accounts.
That said, I got a Proton family account and switched, in Proton Pass it is much more intuitive and easy to share with family (just say: share this folder with that fam member, read or read/write), since you don't need the whole "Organizations" layer needed in Bit/Vaultwarden (which also has it's ups, I know). Happy to report that Vaultwarden exported everything nicely to .json and importing into Proton Pass was flawless.
I also find Proton Pass to be a bit more helpful in associating urls with credentials, + I now use the 1 alias per login (each credential set has a unique email address) without any effort, Vaultwarden can't do that (yet? Although seems complicated to implement), only (paid) Bitwarden I guess.
That's the whole point of SaaS isn't it? We pay you to manage this, you manage it appropriately taking advantage of economies of scale, we sue the shit outta you if it goes wrong.
Generally, you cannot.
Your identity is still stolen, your private photos leaked, your company destroyed, etc.
Pretty sure the entire point of SaaS is that sweet recurring revenue.
Doesn't matter if the downtime is higher, doesn't matter if there are more succesful attacks.
If a CTO goes in-house, they carry the risk. If they outsource it to a vendor, especially one with a Gartner report, they can play golf and not risk their bonus.
I don't really understand why people bother with this security theater, all the self hosting is completely redundant.
2) SOC2 is defined by the American Institute of Certified Public Accountants. That it is held up as some sort of exemplary cyber security standard is absolutely ridiculous.
If the cost of your security policy is greater then the cost of a worst case compromise then you are probably over investing in security.
With that in mind, does your policy seem appropriate to a user securing their Facebook password? Or their homelab service accounts?
*Cost in this case being the combination of literal currency and subjective costs like time/emotional well-being/public perception.
In that case, it's extra silly. Is the cost of setting this up and maintaining it at all worth securing your Facebook password?
And that is without even accounting for the amount of knowledge and experience gained by self hosting.
To me (and I'm pretty ignorant about this stuff), the biggest weakness of a password manager is that it's the one link in a chain that somebody needs to break to have all of my passwords. Hosting that at bitwarden.com or lastpass.com or whatever makes it an even sweeter target because those are known targets. At least self-hosting makes it more difficult for somebody else to find my password manager.
Moving to Vaultwarden has its complications but it would also be fun, and maybe a cool project for the kids. And like you say, if we screw up and they lose their instagram password they won't even remember the pain once they've all grown up and the world is a dystopian nightmare of climate catastrophes, wars, etc. They'll be busy looking for the fattest grubs to eat.
I got hacked less often than 1Password or Okta, so I guess I am on par with the professionals, afaik (I give you that) :)
As another poster mentioned, if some state-based actor gets interested in me, I'm hosed no matter what.
1. If for some reason a state-based actor takes interest in me, I'm boned no matter what I do. I wouldn't trust any hosted service in that circumstance and that includes the service I'm running Vaultwarden on. My vault isn't even what they'd necessarily attack; they'll go straight after my bank and straight after my other high-value accounts and there's nothing I can do about that either.
2. My self-hosted Vaultwarden setup will defeat any random scanner and the majority of random Joe Schmoe Hacker guys. In principle it even defeats a casual insider on my hosting service because just grabbing a disk image actually shouldn't help them much; they need to compromise Vaultwarden (not just the OS generally, Vaultwarden specifically) somehow, and probably actually my Vaultwarden client too.
The rest of your concerns hypothesize a class of attacker I think borders on, but is perhaps not quite, nonexistent. I'm not really concerned about the super-skilled hacker, who is limited to only my vault as their attack vector, and apparently has very fresh if not zero-day vulns that they are willing to deploy against me and specifically me, only me, their payoff for their personalized and specialized hacking effort is just that they get specifically my (encrypted) vault and nobody else's. That is a very specific level[1] of interest in me this hacker, that is not defeated by my current setup, but is defeated by what you outline, has in me.
Edit: Actually what makes me the most nervous overall is compromises of the client, not the self-hosted server I run. For practical purposes 100% of my risk in this setup is there.
I lean on Tailscale to avoid exposing the server to the public internet. That doesn't handle the backup and restore concern, but unless I'm missing something I should be pretty well mitigated on network security issues since I avoided firewall and port configuration all together.
- Build a straw man argument
- Act like all threat models are the same (distributed vs. centralized password store, for example).
So the real question for me would be why not use KeePass, which is what I used before switching to Bitwarden. I switched because at the time, Bitwarden had better clients, better integration with Android and Firefox. That situation has changed some since, but I haven't had any good reason to switch back.
Based on that, the rest of your comment is useless fearmongering
I used it in conjunction with Vaultwarden for a year with the idea that I'd evaluate it as a family-wide replacement for 1P.
In the end I went back to 1P.
1P does some things amazingly well. Here's the shortlist:
- It loads quickly. This wasn't the reason I went back to 1P, but it loads an order of magnitude more quickly than any of Bitwarden's clients: Windows, Linux, iOS, Mac. Bitwarden is slow, slow, slow. I was willing to put up with it for freedom. I wanted Electron 1P to be awful. It's not. Electron Bitwarden kinda is...
- The (I can't believe I'm saying this) killer feature: being able to sort passwords by date (or well - being able to sort at all). If you use a password manager long enough, you'll have a lot of passwords. Sometimes you need to find one manually. Bitwarden made this far more difficult than it needs to be. There's no way to sort the passwords. You have to use the (lackluster) search.
- 1P can put your most recent passwords, secrets and make them easily accessible by default. Yep, more sorting issues. This is particularly helpful in my work related to software and infra development. There are often a lot of secrets, especially during spikes. It's nice to not have to hunt for them too much.
- Shared vaults are better with 1P. Easy to move secrets, easy to de-dupe. Etc. etc.
Everything about Bitwarden is fine for a single, technical user, but it's not for sharing secrets with non-technical family members at any scale. It's just too clumsy with too many sharp edges.
I really, really wanted to leave 1P behind. But I came back to it. And I don't regret it.
Agreed. The good news is this is changing, they have native apps already in beta: https://bitwarden.com/blog/native-mobile-apps/
I'm using the Android beta and can confirm it's much faster.
https://play.google.com/store/apps/details?id=com.x8bit.bitw...
Web Android beta link:
https://play.google.com/apps/testing/com.x8bit.bitwarden.bet...
The Electron app (for desktop) and browser extensions are indeed slower than they could be, and native mobile apps won't fix that.
Bitwarden isn't rapid, but at the time it was, to my surprise, a better experience than 1P, at least on MacOS.
I don't know. I guess it depends on what you compare it to. I've used Bitwarden in some pretty non-technical surroundings and it worked fine. Compared to a "single file" PW manager (like KeePass), I'd say it's still pretty easy to use within a team or group of "non-technical" users.
Granted, not as good as 1PW, but still a lot better than KeePass et al.
Also, I get a lot of mileage out of the Fastmail "masked email" integration with 1P
I also still run KeePassXC just for its GPG agent support, which 1P hasn't (and I suspect won't) supported. I think 1P is all-in on using SSH keys to sign commits, which yes, is one GPG use case, but come on