关于自建 bitwarden 安全性

[takanashisakura]

如题，题主使用家用 nas ，采用开源版本的 vaultwarden/server 的 docker 镜像搭建了 bitwarden 服务。为了方便使用域名访问，是通过有公网 ip 的服务器，采用 nginx 反向代理的模式进行的内网穿透。

公网服务器和内网 nas 之间通过 tailscale 打通的，使用 tailscale 的 acl 限制公网服务器仅可以访问 bitwarden 提供服务的端口，例如映射的 8080,然后再通过公网服务器的 nginx 反向代理把 nas 的服务配置在对应的子域名下。公网服务器前面还有一层 cloudflare 的代理和 ssl 加密，不知道这样是否还存在一些比较大的风险？

网络结构大概这样：

[Noicdi]

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

[shirasu]

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

[Huelse]

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

[yaott2020]

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

[DataSheep]

cf tunnel +1

[ZhiyuanLin]

不放心还能加个 Mutual TLS

[billlee]

@yaott2020 cloudflare tunnel 会受到 gfw 影响吧

[momooc]

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

[momooc]

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

[iphoneXr]

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

[takanashisakura]

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

[takanashisakura]

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

[Noicdi]

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

[dudewei]

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

[momooc]

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

[0x535]

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

[lekai63]

要么本地搭建 cf tunnel 暴露出去

要么服务器部署 挂一层 cf

叠加的收益是什么？

———

危险点：主密码、bw 0day 、服务器因其他问题被攻破

[dna1982]

费时费力不讨好
我用 Keepass

[shijingshijing]

这种图是什么画的？ Drawio?

[neroxps]

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