如题，题主使用家用 nas ，采用开源版本的 vaultwarden/server 的 docker 镜像搭建了 bitwarden 服务。为了方便使用域名访问，是通过有公网 ip 的服务器，采用 nginx 反向代理的模式进行的内网穿透。
公网服务器和内网 nas 之间通过 tailscale 打通的，使用 tailscale 的 acl 限制公网服务器仅可以访问 bitwarden 提供服务的端口，例如映射的 8080,然后再通过公网服务器的 nginx 反向代理把 nas 的服务配置在对应的子域名下。公网服务器前面还有一层 cloudflare 的代理和 ssl 加密，不知道这样是否还存在一些比较大的风险？
网络结构大概这样：

网络层面我不了解，但是在使用上我有一个建议，重要的账户密码采取两步密码，服务器上记录的秘密是实际密码的子串

记录的是密码的字串是什么意思？不太明白，可以详细说一下吗？

理论上最危险的是你的客户端和你的主账号密码，https 是不用担心的，不然一众翻墙手段早就 G 了。

直接在 nas 上部署 cloudflare tunnel 不是更好吗

cf tunnel +1

不放心还能加个 Mutual TLS

cloudflare tunnel 会受到 gfw 影响吧

要啥 cf ，慢死了，直接 https 反代本地 8080

主密码弄长点复杂点加上 Toto ，本地多备份，可以 gpg 、AES 加密备份坚果阿里云

bitwarden 浏览器插件-设置-安全-密码库超时 选择 从不 。哈哈 我觉得我的最大的风险点 应该就是这个了。

你是想说 totp 的两步验证吗？ cf 套在公网服务器的前面，一是因为我域名在 cf 托管，二是 cf 代理可以隐藏主机 ip 吧，所以顺带开了。

cf tunnel 好像之前看到有些问题，然后我之前实际上是用的 tailscale 把 nas 和笔记本做的共享。最近是因为手机上使用有点不太方便，所以走公网服务器的 nginx 做了个反代。

＃2 假设我的微信的实际密码是 123456abc ，我在 bitwarden 上的密码记录的是 123456 ，然后在实际填密码时还会补上 abc 。这个做法包括但不限于开头、中间和结尾补密码，特定位换密码。类似于两步验证

bitwarden, lastpass 这种产品，最大的安全问题可能不在于你的网络传输（当然网络传输也重要），而在于你的 主密码到底有多长。如果不是 15 个以上的随机混合字符串，那就自求多福吧。看看去年 lastpass 被偷走的数据，现在开始很多人的数据被破解出来了。比如下面这个 bgr.com/tech/last-years-lastpass-security-breach-was-linked-to-35-million-in-crypto-heists/

o 和 p 太近了点太快，你有服务器还用 nas 吗，多此一举

我认为这种服务放在局域网就够了。安全和便利总是要做一点取舍的。

要么本地搭建 cf tunnel 暴露出去要么服务器部署 挂一层 cf叠加的收益是什么？———危险点：主密码、bw 0day 、服务器因其他问题被攻破

费时费力不讨好我用 Keepass

这种图是什么画的？ Drawio?

早期 keepass 的 ios 客户端难用的一批。客户端还是 bitwarden 最舒服（免费的）

与网络相比，自建密码库最大的风险就是数据损坏。简单来说，如果你真的要自建，那么你需要：1. 定期备份你的密码库文件，备份到另一个物理盘。
2. 异地备份你的密码（比如同时用 biwarden 和 chrome /icloud 来记录同一个网站）
3. 定期导出为其他密码管理器的格式，并加密存储（比如使用 veracrypt ，放入存储中，这个文件你可以放心在网盘中备份）大多数自建的人，会遇到悲惨命运，就是因为没有考虑到数据风险而只考虑了网络通讯风险

当然是 Keepass, 坚果云 webdav 支持历史版本. 密钥在本地.

最大的风险就是电脑被偷了.我没设置主密码.

其实还好 同步到手机上 服务端崩了，手机里的还在，原来服务端直接删了，起个 docker ，把手机的恢复过去

主密码 20 位包含大小写特殊字符，开了 2FA ，密码文件每 5 分钟打个加密压缩包 rclone 到谷歌 drive ，关闭新用户注册。

0day ，cf 那边的风险这两者的风险你无法控制，剩下的只要你没有弱密码，保持安全更新就不会有啥问题，甚至说自建只是自用的话的风险比官方服务都要小，因为谁知道你的这个服务。

github.com/jeessy2/backup-x简单的备份任务即可。定期打压缩包

自建 Bitwarden (Vaultwarden) 稳定用了至少三年了 上面存了我几乎所有帐号所有密码 期间迁移过服务器我的方案是直接 Docker 拉起镜像 + Cloudflared Tunnel ，每天定时 SQLite 备份数据库 + 打包压缩静态文件，然后 Rclone 同步到 Google Drive 加密盘只保留过往两周的记录，所以个人 15G 绰绰有余了迁移就直接关掉服务然后整个文件夹拷走再重新部署稳定性还是很强的，我目前服务运行三年，一次都没挂掉，也没动用备份恢复过数据

不建议使用 NAS 储存，增加了复杂度，性能要求很低，用闲置的 VPS 搭建更合适，日常访问挂代理就好。

我是用云函数自建的，阿里云的函数计算能直接跑镜像，超级便宜，一个月用不到一毛钱

建议直接通过 vpn 访问 nas 里的服务, 别暴露在公网上

cf tunnel ，简单粗暴，这种也不需要多快网速，偶尔断网也无所谓，都在本地存着

侧重点请放在备份上，不要担心网络传输的安全性，也不用担心服务器上数据的安全性bitwarden 的明文只存在于客户端在你输入主密码解锁后的内存中 bitwarden.com/help/bitwarden-security-white-paper/ 你只需要信任你的客户端，不需要信任任何网络或是服务器记得禁用 web github.com/dani-garcia/vaultwarden/blob/cec1e87679cfd0e2f0bce9b7dc3256dbbd2effa8/.env.template＃L70建议你读一遍这个 env 文件里每项的注释，非必要的都禁用掉，不懂的选项在 issues 里搜一下

bitwarden 拿到数据库都不能解密，只有自己的主密码可以解开。

注意一下默认设置，不需要的功能可以全部禁用，修改加密方式为 Argon2 （不知道现在是不是默认启用，可能是），定时的备份数据库到其他设备。BW 最让我不满意的点就是绑定了账户，需要一个服务器登录账号才能同步使用，如果服务端坏了可能造成非常大的麻烦。Server-first 让我有点不爽，这一点上我更喜欢 enpass ，但是 enpass 也更加的封闭，不够透明。

具体说说, 是否写了教程, 谢谢

定时加密备份到多个云盘。我是两天一备份的。

＃13 那这个需要补充的子串，以及补充的位置是什么记忆的？不同网站之间有什么规律吗？

我是没把端口放出去的 tailscale 打通了用的，放出去怕有问题

docker 部署,data 目录挂载,wg 后访问,每天定时备份 data 目录,gpg 加密后放 dropbox

＃38 这个就纯看个人了，补充的子串可以是个人名字的缩写，或者特殊意义的字符串，或者待登陆网站的域名；位置可以放结尾也能放开头。这些纯看你怎么舒服怎么来。况且不是所有账号的密码都这么搞，我只把几个关键账号的密码这么操作了，其他的就直接存 bitwarden 里了

bitwarden 安卓用不了 还是老老实实 1PASS

bitwarden 最重要的就是记住账号和主密码服务器是次要的，数据库中只保存加密数据，拿到数据库也需要账号对应的主密码解密，备份倒是有必要，虽然 ios 客户端在服务器宕掉也能使用和导出，但是可以避免误删数据传输过程更不用担心，传的都是数据库加密数据，解密是在客户端输入主密码之后完成的

安卓正常用啊 不过我很少用手机来输入账号密码

我懒，所以只选现成服务省时间。bit 这种自建的，尤其是密码这种极其重要的数据，还得想办法去多份异地备份，服务器也得加强安全防护。

这个方法妙啊

＃42 什么地方用不了？我用了很久，没发现你说用不了的情况

阿里云的云函数跑镜像？能具体说说咋建的吗？

如果能连上的话，可以试试 cf 的 zero trust ，直接丢在局域网网段里

cf tunnel +1