My own "justification" is that while self-hosted is my main personal store, I maintain a paid but empty account with Bitwarden. Said empty account on their servers is to be the emergency access person for family members' personal official vaults. So, they get some money for a license out of me, without the server usage.
I subscribed for two reasons: 1. To support their efforts and 2. They accept Bitcoin (and of course I paid with Bitcoin although the whole payment processing was garbage).
Similar here... I also trust them to maintain their service slightly better than I trust myself to do so. I like supporting the project in general as well.
Same here too for personal/family vaults. Have been using the bitwarden cloud offering in professional context too.
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.
I did too, and liked it until it taught me a valuable lesson about self hosting things. I started using the project while it was still called bitwarden-rs. Apparently they were told to rename by Bitwarden (understandable).
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.
One big caveat to this is that it is only used for authorization - you still need your master password to unlock the vault. Kinda pointless imo. There is a component called the key connector which can allow unlocking of the vault with sso but that key connector is not in the PR and it is unknown if vaultwarden will ever implement it.
Vaultwarden is impressive. Years of work without issue. It supports Yubikey now.
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.
Yes, phishing is a concern, but is addressed by the same Yubikey. Most websites that matter support it.
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.
For sharing, I use diceware passphrases (with few words quickly typed in iOS keychain). With autocomplete it’s quick.
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.
My main issue with Vaultwarden is that there doesn't appear to be any way to migrate a Bitwarden self-hosted instance to it. I run a Bitwarden server for myself and something like 5-10 family & friends so manually migrating everyone's data is tough.
I'd really love to try Vaultwarden as Bitwarden is pretty heavy on the little server it runs on
I evaluated this for a small business but came to the conclusion that self hosting this security critical software would cost more in work hours for initial setup and maintenance than just paying the cloud fees for a few years.
Genuine question, in what scenario is the self hosting setup and maintenance worth it?
There really isn't any maintenance besides the occasional update. Setup was also effortless as I've got Caddy setup to reverse proxy containers in my network. I simply define what the subdomain should be for the container and where it can reach it and that's all there is to it.
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.
> Genuine question, in what scenario is the self hosting setup and maintenance worth it?
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.
Another reason for NOT self hosting: I want the passwords for my family to be available in the event something happens to me. The probability of Bitwarden being more resilient (at least mid-term) is much higher than any self hosting solution I would come up with.
If you've opened it once on a device and haven't logged out, the encrypted vault is still available on that device and can be unlocked and read. You just can't modify it. There were bugs in the browser extension that made it log out without the user asking it to, but those should be fixed.
In which client? There's no technical requirement for that to be so.
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've never had that issue in multiple years with spotty internet. What I have is clients that stay out of date and don't always immediately sync. Even when the Internet is fine. Sometimes even a restart wont force a sync.
This is genuinely an underrated problem. This extends to a bunch of tech things in my life… if our Plex server were to fail everyone would be able to survive but we have a whole smart home setup with Home Assistant and if that fails the lights are going to stop turning on correctly.
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.
>in what scenario is the self hosting setup and maintenance worth it?
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.
Not a business here, though using certain self hosted tools has paid off in work as well.
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.
The container itself needed no maintenance at all in my experience. Just update it. The DNS and reverse proxy if you use one are separate though, and depends on your setup.
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.
Evaluating these decisions one by one doesn't make sense. Yes, if you are looking at just the cost of setting up Vaultwarden, there's a significant amount of stuff to learn & practice to keep it up.
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
>Genuine question, in what scenario is the self hosting setup and maintenance worth it?
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.
Is there a good argument for actually using Rust for such things?
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?
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.
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.
I do the same thing across my (meagre) docker infrastructure, and the reason is simple: If the code isn't running, I know I can just do a disk backup of the target system. Docker is also helpful because I can know beyond a shadow of a doubt that the things that can change are on the mounted volumes and it is not possible for something important that I should be backing up to be hiding out in some directory I didn't realize it was using.
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.
You hit the nail on the head and that is exactly why I do it that way. I don't have to worry about all the different ways different databases need to be backed up if they are running and the outage window is measured in seconds in the middle of the night.
Fun story, I booted up a Windows 8 tablet I had not touched for years. I looked at Firefox, and noticed my long lost LastPass, which I lost the vault for... I logged in offline, and wouldn't you know it, I was able to see all my (mostly useless by now) passwords, going back 10+ years.
I have successfully used this for some time, but migrated away to just pass because synchronizing a pass "db" with syncthing tends to work much better.
I switched away from KeePassXC because I kept having sync issues with the DB :). Could have something to do with the way I work (always several PC on/active and my own NextCloud install with issues from time to time...). Vaultwarden never had any sync issues. I guess because changing one login will give you 2 versions of the entire database when a conflict occurs, for Vaultwarden, it's just that one credential, which hardly ever happens.
KeepassXC can sync changes between your opened database and the (modified) file on your storage. However, you need to make sure your sync tool doesn’t see conflicts and renames the file, i.e. don’t save the database on multiple systems at nearly the same time.
Oh that is nice, but NextCloud never made effective use of that. It's been a while but I also found the browser plugins and methods to use the DB on mobile platforms cumbersome. Idk, perhaps much has changed, I have been on Vaultwarden for years now, and more recently switched to Proton Pass. Both have excellent Web UIs, iOS/Android apps and browser plugins.
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).
When you all self-host this, you also do the following, right?
- 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.
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.
You posed it as a joke, but it's quite true: the "real deal" professionals get hacked frequently. Doing the barebone basics will protect you from 99% of the crap out there.
As another poster mentioned, if some state-based actor gets interested in me, I'm hosed no matter what.
For me it is worth it to host a password manager for me and my family, although I just did a one-click install on Digital Ocean (using Bitwarden, not Vaultwarden ... so far).
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.
The vault is client side encrypted so it doesn't actually matter. My host provider could be the robot devil living in North Korea and it wouldn't matter, that's literally the defined purpose of encryption, secure communication across adversarial channels.
I don't really understand why people bother with this security theater, all the self hosting is completely redundant.
I don't self host because of "security theater". I do it because I want to control my data and not be at the behest of a third-party to resist the siren song of enshittification.
1) I’m going to go out on a limb and guess Lastpass, Okta, et al., WERE and ARE SOC2 type II certified. Didn’t stop them from getting breached.
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.
Not to defend them, but it doesn't matter if a hosting provider does that. So long as you can sue them for your full damages when it goes wrong.
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.
The whole point of saas is someone the CTO can blame when things go wrong.
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.
Or, you might pay an insurance company to cover you for the risk - and so long as you have the right attestations from your SaaS providers, your insurer pays out in the event of a problem (and maybe goes after the SaaS if they feel the need to).
The bigger risk is likely your client, which might even be inside your browser, gets hacked / compromised. And that is the same regardless if you self-host.
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.
I don't currently self-host Vaultwarden, though I do have quite a few services running on my home server.
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.
Well, first off, Strongbox is Apple specific, and I don't use Apple devices. Second, it does not appear to be 100% open source, though it is based on some open source code from KeePass.
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.
I wouldn't use this because six months from now this very well meaning developer may sell the company to a buyer who ends up being less scrupulous. You're one update away from losing control of your entire digital life.
After being fed up with AgileBits' (1P's owner) shenanigans (hiding critical threads on their user forum, ignoring customer voices wilfully, being generally dismissive of criticism), I decided to give Bitwarden a try.
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.
I never found the mobile apps to be slow (they're "semi-native", made in Xamarin, in the same way React Native is "semi-native"). The Android integration is not great (it misses password fields sometimes) but this is because of the platform itself, not the current app architecture.
The Electron app (for desktop) and browser extensions are indeed slower than they could be, and native mobile apps won't fix that.
I’ve switched from 1P to Strongbox which is using a Keepass2-compatible database in the background. But Strongbox integrates into the Apple AutoFill API so it works (and mostly feels) like the native Apple Keychain thing. Only for Chrome or Firefox you’ll need a plugin and then it works similar to Bitwarden. But I don’t use these.
> 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 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.
I am also firmly a "tags versus folders" person, since an AWS credential is both "aws" and "qa"
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
And yet they can’t do folders or nested tags, which makes it unusable for me. All those other features are useless when it can’t handle basic organization.
This does not appear to be true - just tried with the beta and regular Android app with wifi + data off, and was able to access my credentials just fine.
Why downvote a valid, relevant anecdote? I'm using the browser extension on Chrome and have encountered being booted back to the login screen a few times. And I certainly want to avoid dependency on my own infra when it holds credentials that would enable me to fix said infra.
