Vaultwarden:把密码主权还给自己

Vaultwarden:把密码主权还给自己

密码管理器的选择,本质上是在回答一个问题:你的账号密码,最终由谁说了算。市面上的方案大致分三类——Google、iOS 自带的密码管理功能,1Password、Bitwarden 官方云这类商业订阅服务,以及像 Vaultwarden 这样可以自己搭建的开源服务器。这篇文章重点说说 Vaultwarden,它和前两类比起来,好在哪,以及很多人担心的”自己搭的服务器挂了怎么办”这个问题,到底有没有那么可怕。

Vaultwarden 是什么

Vaultwarden(前身叫 bitwarden_rs)是一个用 Rust 写的、非官方的 Bitwarden 兼容服务器。它完全开源,运行起来对内存和 CPU 的消耗都很小,装在树莓派、家用 NAS 或者一台配置很低的云服务器上都没问题。

它最关键的一点是:完整兼容 Bitwarden 官方的客户端生态。也就是说,手机上的 iOS/Android App、浏览器插件、电脑桌面端,都可以直接拿来用,只需要在设置里把服务器地址指向自己搭的 Vaultwarden 实例即可。你不需要用什么特殊客户端,体验和用官方 Bitwarden 云服务几乎没有差别。

三类方案的核心对比

把 Vaultwarden、系统内置方案(Google 密码管理器、iCloud 钥匙串)、商业在线服务(1Password 等)放在一起看,差异主要体现在数据归属、跨平台体验和费用上。

对比维度Vaultwarden(自托管)系统内置(Google/iCloud)商业在线服务(1Password等)
数据归属完全在自己指定的服务器上绑定在 Google/Apple 账号体系里存在服务商的云端
跨平台体验全平台一致,不挑系统换生态就割裂(如 iOS 上用 Google)全平台支持较完善
高级功能(TOTP、共享等)免费全部解锁大多不支持需持续订阅付费
断网/服务器不可用时本地缓存,照常使用依赖云端同步,换设备且断网就取不到本地缓存,但账号被封风险仍在
维护成本需要自己配置、更新零维护零维护,长期花费较高

数据自主:不被任何一方”管账”

先说系统内置方案。它最大的隐患是账号绑定——如果 Google 账号因为某些原因被封,或者 Apple ID 被安全锁定,存在里面的所有密码可能一夜之间都取不出来了。这不是危言耸听,而是账号体系本身的设计决定的:密码数据和账号状态是绑在一起的。

再说商业云服务。即便厂商都说自己是”零知识加密”,主密码不泄露黑客就解不开,但你的加密数据库本身依然放在别人的服务器上。历史上确实出现过密码管理器云端数据库被整体拖走的事件——主密码没丢,但网址列表、用户名这类元数据的暴露,本身也是隐患。另外,商业公司还有涨价、调整条款、甚至被收购或倒闭的可能,这些都不是你能控制的变量。

Vaultwarden 的做法是把这套账号体系整个搬到自己手里:没有审核员,没有封号机制,密码数据从头到尾只在你指定的服务器和设备上流转。换手机、换电脑、换生态,都不需要看任何一家科技公司的脸色。

服务器挂了怎么办:其实没那么可怕

很多人第一次接触自托管都会有这个顾虑:家里断电、断网,或者服务器硬件坏了,是不是密码就彻底拿不到了?这其实是个误解,原因在于 Bitwarden 系客户端的运作方式本身就考虑到了这一点。

客户端本地缓存

手机 App、浏览器插件、桌面端都会在本地保留一份用主密码加密过的数据库副本。只要没有主动点击”退出登录”,服务器彻底离线时客户端会自动转入离线模式,解锁、查密码、自动填充都不受影响。

物理层面的备份

Vaultwarden 默认用 SQLite 存储,整个 data 文件夹(包含密码、笔记、二步验证密钥)体积很小,用一条脚本就能定期同步到网盘或移动硬盘。

真到了服务器硬件报废这种极端情况,恢复流程也很简单:找一台新机器装上 Docker,跑起 Vaultwarden,把备份的 data 文件夹挂载进去,几秒钟内数据就 100% 恢复,不需要重新登记任何账号。

对比一下,Google 或 1Password 想备份数据,通常只能手动导出成明文 CSV,这本身反而是个不安全的做法,导出的文件一旦泄露就是明文密码。Vaultwarden 备份的是加密后的数据库文件,即使备份文件被别人拿到,没有主密码依然打不开。

小结

三类方案各有取舍:系统内置省心,但换生态就割裂,还绑定账号风险;商业服务功能齐全、体验统一,但要持续付费,数据也终究放在别人那里;Vaultwarden 需要投入一点搭建和维护的精力,换来的是数据完全自主,加上客户端离线缓存和轻量级备份带来的容灾能力——服务器真的挂了,也不至于一夜回到解放前。

如果已经有 NAS 或者一台闲置的云服务器,搭一个 Vaultwarden 实例的门槛并不高,主要工作量在于配置好 HTTPS 和定期备份这两件事。

分享或订阅:
🧡 喜欢我的内容?欢迎点击 订阅 RSS Feed 获取最新文章更新。