This article is using Vaultwarden, not the Bitwarden server. It's wrongly referring to Vaultwarden as "BYOPM hosts a Bitwarden instance" and "the Docker Image of Bitwarden." It is not, it is hosting a Vaultwarden instance. This is an issue as people using Vaultwarden report bugs to the Bitwarden project, where they can't be helped.
I've seen so many interesting password manager solutions over the years, but I have yet to move away from a Keepass file hosted on cloud storage. I can read and write to it using apps from every device I use: windows and linux PCs, iOS and Android devices. The file is versioned so accidentally clobbering it isn't a concern. There is zero maintenance, and if my home server goes down my passwords are unaffected. If I'm going somewhere without internet and need a backup mechanism of getting to my passwords, I can copy the database onto a memory stick.
What happens when there's more than you who uses the Keepass file and how do you store new passwords to the file when you create new accounts on the web (for various services)?
What's the usage flow? Is there browser extension that allows you to interact with it without opening Keepass program?
Maintenance you described is easy, but what about the actual usage and sharing passwords?
Good questions and I think they show some of the blind spots I have.
I don't share my passwords database. Right now my wife and I do have a very limited number of shared accounts but I set up the same system for her and we simply duplicate the few shared logins we have in our two databases. This could be an issue if we need to share more.
Creating new accounts is easy. Both my windows and iOS Keepass clients open the file directly from cloud storage. They can save changes and reload the database on startup. Once in a while I've had conflicting writes but it's rare, and I stopped getting them when I got better about saving and closing after changes.
Usage flow on PC (I'm sure I could install a browser extension, but haven't bothered yet):
1. oh I need a password. windows+s, type keepass, open keepass, type master password.
2. ctrl+e look for the website I'm on
3. ctrl+b copy username, paste
4. ctrl+c copy password, paste
Usage flow on iOS:
1. oh I need a password. iOS magically knows, gives me options of iCloud keychain or Keepass client. Select Keepass client
2. Sometimes it's not smart enough to detect which password entry to use. In this case, type in the website/app name and select it
3. Usually it's smart enough to fill out the username & password fields automatically
Oh, that's neat. What iOS app do you use? I've been using minikeepass but it has been no longer supported for a while now (I've got a copy of the .kdbx for my phone elsewhere, so when it eventually self-destructs I'll still have that at least).
I use Strongbox, with Keepass databases stored in iCloud. One for me, one for wife, and one for both of us for mutual accounts. Periodically they are backed up to a USB drive to store with important documents. And Time Machine backs them up regularly to NAS.
We also use macOS/iOS keychain for convenience, but the TOTP and other notes about the account are stored in Keepass database.
Not OP. I add only from my laptop, I share with Syncthing to my other devices. Nobody else use my passwords. If a customer has a per team password they either never change it or in the very rare cases they do, they tell me the new password when I ask why the old one doesn't work anymore. They don't let me in their shared password manager anyway (only one customer has one.)
I have a personal Nextcloud instance set up on a VPN. We have a "shared" keepass file that is shared between the two of us, and individual one for each of us, which is not shared via Nextcloud but still syncs to Nextcloud to have available on our computers/phones.
This has worked great for us for a number of years.
We have been encrypting the key file with our SSH keys and share it along the database in a private GitHub repo. Additionally we have a single memorable password as preshared key. Works well for our small admin group.
What's the use case for sharing passwords? I've never had the need to share one in 20+ years of being a power user. If I end up dead, my master password will be shared in my will with appropriate parties.
> Is there browser extension that allows you to interact with it without opening Keepass program?
My wife and I have a number of accounts we share a single credential for. There are a surprising number of services we access as parents that don't have the concept of shared ownership of content on the server side.
I'd bet there are other use cases as well. Off the top of my head, Hello Fresh also doesn't allow more than one login to manage the same subscription.
Unless you live alone and have no family, there are all sorts of scenarios for sharing passwords.
Fedex/UPS only lets one account get detailed tracking numbers for an address, so I need to share my Fedex account. To check and pay my freeway tolls I'm only allowed a single account - so it gets shared. Plenty of people share all sorts of subscriptions, be they to Netflix, the New Yorker, or more. I need to share access to my insurance, to the utility bills, to sporting event tickets, to grocery store and pet food orders. On and on and on.
Also, for many of my accounts today, I use "Sign in with Google" so it's not even possible for me to share a password or credentials unless I share my whole Google account shebang.
For personal use: none for me. Instructions for deriving/obtaining my master password and physical key will be made available in any will or power of attorney documentation I get around to drawing up.
In DayJob there are several, though they are usually only temporary needs, such as:
1. We often get sent password-protected documents by clients, that more than one of us needs to read. It pains me how often I see an attached document on an email containing the password needed to open it… A shared password manager where someone can record the credential and mark who should be able to access it (or better have all credentials encrypted by the public keys of those who should be able to access them rather than just trusting a flag) would be less daftly insecure.
2. Distributing initial credentials for new assets or to new people, where those assets are not integrated with single-sign-on so nothing needs to be distributed anyway.
There are other ways to manage such situations of course, but a password management arrangement with a well-defined way of sharing credentials may encourage behaviour more secure than some of the ad-hoc solutions people regularly use.
Internally I do something very similar: drop the information to a share on my machine with read permissions set to the right people.
As you say, things can be more complicated for externals. I often don't have write access to much that they can read from, without putting in a request through infrastructure, for obvious separation-of-concerns reasons, because things we host/manage directly for them are well locked down, anything at their end is too, and most of our clients have white-list-only access to other resources.
Others have mentioned shared family accounts, I could also imagine storing shared wifi keys, or the admin password for the router. In the case of a business/project, there is also storing API keys, and maybe also admin passwords for devices. There could also be non-digital secrets stored in the vault, like bank accounts and social security numbers. The easy solution is just to have a separate keepass file that is meant to be shared, and/or have everyone maintain a separate vault with some of the data duplicated, and manually tell everyone when its time to update their info.
At work we use hashicorp vault, ansible vault, and cyberark for different things, but I still store my stuff in keepass. For personal use, I use keepass on dropbox, and it's worked incredibly well for almost 15 years now.
Why? I'm not suggesting to have an extension that has access to your file system. Bitwarden has browser extension that communicates to Bitwarden vault via HTTP and it's easy to autofill passwords or generate new credentials.
For throwaway accounts or demo accounts or any kind of new web service/app accounts, it's easy to memorize username and autogenerate a strong, safe password which are saved to vault.
You have the access to that same vault from a different device (smartphone etc), it makes interacting with passwords and its storage extremely easy and without mistakes.
A use case isn't hard to imagine. You have a significant other whom you want to share credentials to some website with.
I have quite a few shared passwords in my "family" vault in Bitwarden. Utility websites (electric, gas, water, internet, etc), streaming services, banking, credit cards, mortgage, car payments, car insurance, Chewey (manage pet food auto ship), probably others.
Keeping all of my passwords on a failure-prone SD card acting as a boot drive makes me nervous. I think I'd prefer a SyncThing-based solution for self-hosting a Bitwarden Vault or KeePass file... if I wasn't already a happy customer of Bitwarden's hosting solution.
This is an interesting tech stack, but seems heavy-handed for managing such a small amount of raw data (the l/p list itself).
My solution for the past 14 years has been a simple GPG-encrypted org-mode (text) file. I can get to a password multiple ways from any device. The main way I check one is to open the file in Emacs which prompts for the master password via pinentry. You could also use a keyfile. Usually I just ssh and connect to a tmux session with emacs -nw already running, but I can also decrypt and grep it from the CLI, or clone the private repo its on to do the same locally. I only do anything involving PII or money in a dedicated PureOS VM though, so I generally don't jump through any hoops and it's relatively transparent.
Seems pretty complicated to me. There’s lots of steps involved which increases the chance of something going wrong. For example, the self signed cert will eventually expire, how easy would it be to renew it? How do I keep this up to date?
It would just be a heck of a lot easier to just use KeePass and save the database on a SD card.
An alternative to this is to expose this to your local network and use tailscale to connect to it so you do not have to carry it around while being secure.
That similar to what I was thinking too… instead of carrying around a device, why not have a server that is physically secured somewhere and connect with Wireguard? It could be at home or on a cloud, if you trust that.
Tailscale and wireguard are available for all major devices, including mobile. So, if you do this, your password manager can live anywhere and doesn’t need to be exposed to the main internet at all. You don’t even need SSH/network access to the remote machine, just HTTPS over Wireguard (and local or console access). Everything else can be locked down tight.
honestly to me this falls into the category of LARP security. the entire point of encryption is to move sensitive data across adversarial channels. Meaning, if you trust Bitwarden enough to use it at all there's no benefit to not just using their servers (you keep a local copy of your data anyway).
If you want to keep your data secure by keeping them on you, just use a notebook. Cheaper than this and works without a power chord.
It not so much that I do not trust the company today, it is that I do not trust them to not silently become adversarial in the future when the government comes knocking or if they get bought out, or whatever.
This is a bit of attack surface that all hosted cloud solutions share, and it is one that it has never been easier to eliminate.
all of these password managers (including bitwarden) encrypt your data end-to-end and nothing ever leaves your client in a plain state so regardless of who has the backend your data is never touchable. You always only ever need to trust the client, which you do here as well.
The client is made by the same people at the end of the day, so that is of little comfort.
Also, adversarial does not refer to just possibly breaking encryption, it also applies to daily continuity. I trust my ability to keep a small encrypted password database safe more than I trust some random companies to get bought or change their business model and suddenly I have to decide between a massive Flag Day or paying for something I did not have to before or having some kind of other unwelcome limitation placed on me.
I like controlling my own destiny, thank you very much.
Sincere question - AFAIK, Raspberry PI OS is a Linux distribution like any other, with dependency/distribution issues like any other. Why would using Docker on it be a sad state of affairs, in contrast to using it on any other distribution?
Because a password manager is a tiny piece of software. Instead, it is now a multi-component black box installation with a general purpose operating system running on a full-scale Linux machine with a containerization platform designed for datacenters.
I am not a fan of this kind of redundancy and opaqueness.
When you put it that way, I agree - a password manager should really be implementable as a single statically linked binary.
There seem to be some other Docker features used, like healthcheck [0], and MariaDB seems to be installed, too, so it might be worth considering how much additional OS-dependent complexity would the equivalent functionality without using Docker require. At the very least, you need some kind of service manager to run your program on boot, and restart it on error. At that point, Docker may as well be used as a glorified service manager - just slap your static binary in a `FROM scratch` container, and you're done.
> I am not a fan of this kind of redundancy and opaqueness.
Me neither. But I wouldn't blame Docker itself - it's just a tool. If it wasn't for Docker, some other way of circumventing good engineering would be found :-)
BitWarden isn't all that tiny. I am pretty sure the main reasons for the docker container is that is built with dotnetcore and uses sql server for its database. BitWarden is complicated to install for self-hosting as opposed to using it on PiZero.
That said, I am skeptical of running it on a PiZero. I could see running it on a Pi3 or Pi4 where I can leave it connected to my network and cron backups to a NAS.
Reminds me of someone writing a little status light app (in the macOS menu bar / windows tray) and choosing Electron for that. Something ridiculous like 200MB+ install size and 150MB memory use.
You wanted a banana, but what you've got is a monkey holding a banana, the whole jungle, the continent on which the jungle is growing, the atmosphere for holding evaporated water for irrigating the jungle, the Sun for providing energy to the jungle trees, and the whole universe.
Docker has been a godsend for home labs. People don't need to know where on the filesystem their configs have been scattered (distro dependent). They just need to know how to docker pull and configure their container.
In case you ever wish to change the operating conditions/environment/hardware in the future. Having a consistent operating environment is a big win, in my opinion.
Yes absolutely, but if the hardware requirements for running docker currently doesn't fit on a keychain (a physical one that is), perhaps its not the best choice today for secure password storage.
One reason is that software isn't always distributed in normal distro repositories anymore. People can't (or don't want to) deal with dependency management so they ship an entire (slightly outdated version of an) OS with their application to make deployment foolproof.
The vaultwarden install instructions assume Docker, for example: https://github.com/dani-garcia/vaultwarden. If you want to install native binaries, you're going to have to git fetch/checkout/pull the latest release tag and run `cargo build --features sqlite --release` yourself. Doable in a cronjob, but it'll probably take a compile to build a system like vaultwarden on a low-power ARM core.
Yes, Docker is a black box. You don't know anything, you just launch something without understanding what components it consists of, what are they doing individually, what is their attack surface.
Not to mention that it encourages sloppiness and software bloat. The password manager could be put on a simple MCU device, instead, we have a large non-transparent multi-component installation swept under the rug with Docker. I do not think this is a good thing.
The same can be said of any software that you don't review and compile yourself. Whether I run a Docker container or pull in 500 npm/pip/cargo/gems/composer dependencies, the attack service remains. With Docker these individual layers can be separated and inspected at the very least.
Based on the name, I expected someone to take vaultwarden and make it an αcτµαlly pδrταblε εxεcµταblε that runs on its own without an OS; instead, this is just a quick tutorial for "how to set up vaultwarden".
I much prefer normal systemd services to sandbox my applications but if the software you want to run isn't packaged in some normal, updateable way (like a standard repository) then Docker is definitely the way to go.
That was our approach. Build it into the keyboard, do all the various secrets management (passwords, TOTP, et al) and message encryption behind a data diode (sorta air gapped). And RPi isn't the ideal compute module for it as you don't want a wireless chip on the inside of the "airgap". https://www.anomie.tech/
One thing I would add: a self-signed certificate is not adequate for password transmission. In some ways, it's even worse than transmitting over clear-text http because it provides an illusion of security.
Any actor on your network can man-in-the-middle, provide their own certificate, and you'd be none the wiser.
I'd suggest provisioning LetsEncrypt leaf-node certificate on a node that can respond to HTTP-01 or DNS-01 challenges (don't open your home network to :80 :443 - use a VM in the Cloud to respond to challenges), then transfer the certificate to the Raspberry Pi.
https://letsencrypt.org/docs/challenge-types/
IMO Letsencrypt is way too difficult to bother with for such scenarios: devices that are not open to the internet.
The hassle of forwarding the ports for their verification and having to do it so regularly (3 months) is a real pita.
I used to just pay for yearly certs for this reason but prices have gone up so now I'm back to using self signed. I'd love to set up my own PKI but the tool chain is so complex and many OSes like Android allow apps to opt out of user -added root certificates which makes it very hard to deal with.
Lets encrypt is staggeringly easy for devices that are not "open" to the internet - it supports or has plugins to manage ACME DNS challenge records fully automatically even for private IPs in your home network, and this is just one way to do it. Using letsencrypt to get valid SSL certs easily, automatically and for free for private IPs behind a NAT is something I love using it for!
You never need to expose a webserver to the public internet to use letsencrypt to get a valid SSL certificate, even if IP is in the private RFC range (192.168.x.x, 10.x.x.x, etc etc).
Every single webapp I run internally has a two line automated Caddy/letsencrypt auto configuration, that just works.
To suggest it is way too difficult suggests you haven't tried recently, or are familiar with very old http-based DNS authentication challenges. You do not need to use http-based challenges to use letsencrypt for a long time, although still supported.
It is now so absurdly easy to do, all my personal projects just have valid SSL by default now, even on my internal LAN. All letsencrypt needs is proof of domain ownership- thanks to DNS TXT records, no one needs to host a website/port forward to accomplish that.
But still those ACME records need to be updated every time on my outside DNS server right? Or is it just a static record? That I can do, a dynamic one is very hard with my DNS provider (meaning I still need to do everything manually every 3 months which is not an option).
I also don't really like leaking internal network info in my external DNS provider which is why I run my own internal DNSes. And I use a domain for my internal network which does not really exist in the real world, I don't know if letsencrypt can handle this.
I have indeed not tried it recently, the last time I tried it it was about 1 year since they launched. Trying to script all the firewall rules to open the ports for a second was a real PITA.
I'll have a look at this, thanks for the heads-up.
The pain point here is something like .home.arpa, which is nominally the recommended domain to use for home networks (not .local to avoid conflicts with mDNS IIRC).
There's still no good solution if you're using a domain that's not valid on the net. LE's lookup has to be able to reach the DNS server for the domain. I think it's something the industry as a whole has failed at - ensuring even LAN devices have good security without doing things like "your home network must have a publicly resolveable domain" or "run your own CA".
you could use the dns authentication, just set the ip to the local one this box for the domain you own/will be always use then all you have to be able to do is hit external dns and letsencrypt to update the cert.
afaik you can't because then there are no dns records to verify against. You could use a subdomain of a real tld if you had one though, or just bite the bullet and spend 10 bucks a year.
I have a general question regarding the BitWarden server: How would you rate the security between using the official BitWarden server and self-hosting Vaultwarden?
I am sympathetic (and capable) of self-hosting, but if my instance and my passwords are compromised, the fallout could be catastrophic for me. Am I better of in the long term by just using the BitWarden server and assuming that they have better security than I do, even though they are the even jucier target?
Now I won't lament the overkill in hardware (512MiB RAM for a password manager?), but the lack of protected memory (Smart Card or otherwise) makes this approach imho quite questionable. Lose the device, lose all your passwords?
Something that's been on my mind for some time is the seeming inevitability of getting RCE'd by some innocuous application- web browser, chat app, videogame, whatever. These vluns keep popping up and eventually one might hit me. And if it does, it might come with something targeting keepass and _if_ it does I'm Fucked with an upper case F.
Building a portable terminal that can emulate a keyboard with a reasonable screen for ease of use seems like a fairly reasonable solution.
> Authorizer is a Password Manager for Android. It emulates an HID keyboard over USB and enters your credentials on your target device. Additionally it supports OTP
Yeah, it seems to me that if you use a standalone Pi for your self hosted password manager, then why not just run everything as systemd services. I did something similar on a Pi 3 for the CCC congress event last year using NixOS and it's been running ever since.
I had some luck in the UK where rpi-locator only showed the main SKU, but the sellers had “kit” stock available with a case and charger for like £10 more, on a separate page.
There's still enough lack of good password-manager infrastructure that I'll venture to say that FinalKey is still relevant, even in the face of Ubikey and Fido.
This is cool, but you can just leave it at home plugged into your router. DDNS + Nginx + Let's Encrypt might be easier to set up, and definitely easier to use.
