That guide is wild. By default it allows public registration, shows password hints, requires a reverse proxy for robust TLS but then passes tokens via GET params, runs in the container as root. Recommends fail2ban because it doesn't have any coverage against brute force. Recommends using a custom path for security.
replyThis feels less like a guide on hardening Vaultwarden than a guide on why I should be skeptical about it.
I’m not an expert with web sockets or web development - but re: Get Params, Vaultwarden has to follow the API of the upstream Bitwarden implementation:
replyhttps://github.com/dani-garcia/vaultwarden/discussions/1549#...
The upstream also had this issue, which appeared to be closed without a PR:
Requiring a reverse proxy for TLS is pretty standard, but the rest of those findings are egregious (if they haven't been addressed yet.)
replyThose problems are endemic to all web apps.
replye.g. You can’t just provide software to people that obtains TLS certs on their behalf: you have no idea how their infra is setup.
Hosting any app on your own infra is a serious skill set.
Since it's authored by the vaultwarden collaborators, I would not trust the project any bit of my passwords.
replyPretty similar experience for me, albeit I've only been managing it for about a year.
replyRestore from backup testing was straightforward. We haven't had any problems w/ the application itself.
I used that that hardening guide for my setup. The one I manage is exposed to the Internet and I'm bringing traffic into it via a reverse proxy.