请不要把任何和邀请码有关的内容发到 NAS 节点。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
这是一个创建于 416 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，题主使用家用 nas ，采用开源版本的 vaultwarden/server 的 docker 镜像搭建了 bitwarden 服务。为了方便使用域名访问，是通过有公网 ip 的服务器，采用 nginx 反向代理的模式进行的内网穿透。
公网服务器和内网 nas 之间通过 tailscale 打通的，使用 tailscale 的 acl 限制公网服务器仅可以访问 bitwarden 提供服务的端口，例如映射的 8080,然后再通过公网服务器的 nginx 反向代理把 nas 的服务配置在对应的子域名下。公网服务器前面还有一层 cloudflare 的代理和 ssl 加密，不知道这样是否还存在一些比较大的风险？
网络结构大概这样：
 |
1
Noicdi 2023-11-06 17:10:23 +08:00 via iPhone  2
网络层面我不了解，但是在使用上我有一个建议，重要的账户密码采取两步密码，服务器上记录的秘密是实际密码的子串
|
 |
3
Huelse 2023-11-06 17:14:40 +08:00
理论上最危险的是你的客户端和你的主账号密码，https 是不用担心的，不然一众翻墙手段早就 G 了。
|
 |
4
yaott2020 2023-11-06 17:15:16 +08:00 via Android
直接在 nas 上部署 cloudflare tunnel 不是更好吗
|
 |
5
DataSheep 2023-11-06 17:17:33 +08:00 via iPhone
cf tunnel +1
|
 |
6
ZhiyuanLin 2023-11-06 17:19:44 +08:00
不放心还能加个 Mutual TLS
|
 |
8
momooc 2023-11-06 17:25:21 +08:00 via Android
要啥 cf ，慢死了，直接 https 反代本地 8080
|
|
9
momooc 2023-11-06 17:27:18 +08:00 via Android
主密码弄长点复杂点加上 Toto ，本地多备份，可以 gpg 、AES 加密备份坚果阿里云
|
 |
10
iphoneXr 2023-11-06 17:48:10 +08:00 5
bitwarden 浏览器插件-设置-安全-密码库超时 选择 从不 。
哈哈 我觉得我的最大的风险点 应该就是这个了。 |
 |
11
takanashisakura OP 1
@momooc 你是想说 totp 的两步验证吗？ cf 套在公网服务器的前面，一是因为我域名在 cf 托管，二是 cf 代理可以隐藏主机 ip 吧，所以顺带开了。
|
|
12
takanashisakura OP @yaott2020 cf tunnel 好像之前看到有些问题，然后我之前实际上是用的 tailscale 把 nas 和笔记本做的共享。最近是因为手机上使用有点不太方便，所以走公网服务器的 nginx 做了个反代。
|
|
13
Noicdi 2023-11-06 17:59:23 +08:00 via iPhone 1
@shirasu #2 假设我的微信的实际密码是 123456abc ，我在 bitwarden 上的密码记录的是 123456 ，然后在实际填密码时还会补上 abc 。这个做法包括但不限于开头、中间和结尾补密码，特定位换密码。类似于两步验证
|
 |
14
dudewei 2023-11-06 18:06:20 +08:00 1
bitwarden, lastpass 这种产品，最大的安全问题可能不在于你的网络传输（当然网络传输也重要），而在于你的 主密码到底有多长。
如果不是 15 个以上的随机混合字符串，那就自求多福吧。 看看去年 lastpass 被偷走的数据，现在开始很多人的数据被破解出来了。 比如下面这个 https://bgr.com/tech/last-years-lastpass-security-breach-was-linked-to-35-million-in-crypto-heists/ |
|
15
momooc 2023-11-06 18:08:44 +08:00 via Android
@takanashisakura o 和 p 太近了点太快，你有服务器还用 nas 吗，多此一举
|
 |
16
0x535 2023-11-06 18:24:02 +08:00 via iPhone
我认为这种服务放在局域网就够了。安全和便利总是要做一点取舍的。
|
 |
17
lekai63 2023-11-06 18:33:42 +08:00 via iPhone
要么本地搭建 cf tunnel 暴露出去
要么服务器部署 挂一层 cf 叠加的收益是什么？ ——— 危险点：主密码、bw 0day 、服务器因其他问题被攻破 |
 |
18
dna1982 2023-11-06 18:55:25 +08:00
费时费力不讨好
我用 Keepass |
 |
19
shijingshijing 2023-11-06 19:08:37 +08:00
这种图是什么画的？ Drawio?
|
 |
20
neroxps 2023-11-06 19:13:18 +08:00 via iPhone
@dna1982 早期 keepass 的 ios 客户端难用的一批。客户端还是 bitwarden 最舒服（免费的）
|
 |
21
bao3 2023-11-06 19:39:16 +08:00 1
与网络相比，自建密码库最大的风险就是数据损坏。简单来说，如果你真的要自建，那么你需要：
1. 定期备份你的密码库文件，备份到另一个物理盘。 2. 异地备份你的密码（比如同时用 biwarden 和 chrome /icloud 来记录同一个网站） 3. 定期导出为其他密码管理器的格式，并加密存储（比如使用 veracrypt ，放入存储中，这个文件你可以放心在网盘中备份） 大多数自建的人，会遇到悲惨命运，就是因为没有考虑到数据风险而只考虑了网络通讯风险 |
 |
22
jqtmviyu 2023-11-06 19:53:27 +08:00
当然是 Keepass, 坚果云 webdav 支持历史版本. 密钥在本地.
|
|
23
jqtmviyu 2023-11-06 19:54:11 +08:00
最大的风险就是电脑被偷了.我没设置主密码.
|
 |
24
weak 2023-11-06 20:11:54 +08:00 via iPhone
@bao3 其实还好 同步到手机上 服务端崩了，手机里的还在，原来服务端直接删了，起个 docker ，把手机的恢复过去
|
 |
25
zhhmax 2023-11-06 21:56:38 +08:00
主密码 20 位包含大小写特殊字符，开了 2FA ，密码文件每 5 分钟打个加密压缩包 rclone 到谷歌 drive ，关闭新用户注册。
|
 |
26
IV16SL 2023-11-06 22:10:04 +08:00
0day ，cf 那边的风险这两者的风险你无法控制，剩下的只要你没有弱密码，保持安全更新就不会有啥问题，甚至说自建只是自用的话的风险比官方服务都要小，因为谁知道你的这个服务。
|
|
27
neroxps 2023-11-06 23:09:15 +08:00
|
 |
28
etnperlong 2023-11-06 23:43:41 +08:00
自建 Bitwarden (Vaultwarden) 稳定用了至少三年了 上面存了我几乎所有帐号所有密码 期间迁移过服务器
我的方案是直接 Docker 拉起镜像 + Cloudflared Tunnel ，每天定时 SQLite 备份数据库 + 打包压缩静态文件，然后 Rclone 同步到 Google Drive 加密盘 只保留过往两周的记录，所以个人 15G 绰绰有余了 迁移就直接关掉服务然后整个文件夹拷走再重新部署 稳定性还是很强的，我目前服务运行三年，一次都没挂掉，也没动用备份恢复过数据 |
|
29
etnperlong 2023-11-06 23:46:13 +08:00
@etnperlong 不建议使用 NAS 储存，增加了复杂度，性能要求很低，用闲置的 VPS 搭建更合适，日常访问挂代理就好。
|
 |
30
Northshad0w 2023-11-06 23:48:50 +08:00
我是用云函数自建的，阿里云的函数计算能直接跑镜像，超级便宜，一个月用不到一毛钱
|
 |
31
EthanLau 2023-11-07 00:08:58 +08:00
建议直接通过 vpn 访问 nas 里的服务, 别暴露在公网上
|
 |
32
duduke 2023-11-07 00:13:05 +08:00 via iPhone
cf tunnel ，简单粗暴，这种也不需要多快网速，偶尔断网也无所谓，都在本地存着
|
 |
33
0o0O0o0O0o 2023-11-07 00:33:18 +08:00 via iPhone
侧重点请放在备份上，不要担心网络传输的安全性，也不用担心服务器上数据的安全性
bitwarden 的明文只存在于客户端在你输入主密码解锁后的内存中 https://bitwarden.com/help/bitwarden-security-white-paper/ 你只需要信任你的客户端，不需要信任任何网络或是服务器 记得禁用 web https://github.com/dani-garcia/vaultwarden/blob/cec1e87679cfd0e2f0bce9b7dc3256dbbd2effa8/.env.template#L70 建议你读一遍这个 env 文件里每项的注释，非必要的都禁用掉，不懂的选项在 issues 里搜一下 |
 |
34
liuguang 2023-11-07 00:40:47 +08:00
bitwarden 拿到数据库都不能解密，只有自己的主密码可以解开。
|
 |
35
cosette 2023-11-07 02:09:29 +08:00
注意一下默认设置，不需要的功能可以全部禁用，修改加密方式为 Argon2 （不知道现在是不是默认启用，可能是），定时的备份数据库到其他设备。
BW 最让我不满意的点就是绑定了账户，需要一个服务器登录账号才能同步使用，如果服务端坏了可能造成非常大的麻烦。Server-first 让我有点不爽，这一点上我更喜欢 enpass ，但是 enpass 也更加的封闭，不够透明。 |
 |
36
wzw 2023-11-07 07:46:30 +08:00
@Northshad0w 具体说说, 是否写了教程, 谢谢
|
 |
38
YangWaleed 2023-11-07 09:04:03 +08:00
@Noicdi #13 那这个需要补充的子串，以及补充的位置是什么记忆的？
不同网站之间有什么规律吗？ |
 |
39
token10086 2023-11-07 09:31:08 +08:00
我是没把端口放出去的 tailscale 打通了用的，放出去怕有问题
|
 |
40
redial39 2023-11-07 09:39:12 +08:00
docker 部署,data 目录挂载,wg 后访问,每天定时备份 data 目录,gpg 加密后放 dropbox
|
|
41
Noicdi 2023-11-07 09:45:44 +08:00 via iPhone
@YangWaleed #38 这个就纯看个人了，补充的子串可以是个人名字的缩写，或者特殊意义的字符串，或者待登陆网站的域名；位置可以放结尾也能放开头。
这些纯看你怎么舒服怎么来。 况且不是所有账号的密码都这么搞，我只把几个关键账号的密码这么操作了，其他的就直接存 bitwarden 里了 |
 |
42
owwo 2023-11-07 09:56:06 +08:00
bitwarden 安卓用不了 还是老老实实 1PASS
|
 |
43
mdn 2023-11-07 10:24:45 +08:00
bitwarden 最重要的就是记住账号和主密码
服务器是次要的，数据库中只保存加密数据，拿到数据库也需要账号对应的主密码解密，备份倒是有必要，虽然 ios 客户端在服务器宕掉也能使用和导出，但是可以避免误删数据 传输过程更不用担心，传的都是数据库加密数据，解密是在客户端输入主密码之后完成的 |
 |
44
dislazy2023 2023-11-07 10:28:42 +08:00
@owwo 安卓正常用啊 不过我很少用手机来输入账号密码
|
 |
45
tyzrj766 2023-11-07 10:31:22 +08:00
我懒，所以只选现成服务省时间。bit 这种自建的，尤其是密码这种极其重要的数据，还得想办法去多份异地备份，服务器也得加强安全防护。
|
 |
48
cnkuner 2023-11-07 11:01:06 +08:00
@Northshad0w 阿里云的云函数跑镜像？能具体说说咋建的吗？
|
 |
49
jackmod 2023-11-07 11:01:10 +08:00
如果能连上的话，可以试试 cf 的 zero trust ，直接丢在局域网网段里
|
 |
50
maniaccn 2023-11-07 13:44:49 +08:00
cf tunnel +1
|
|
51
YangWaleed 2023-11-07 23:12:45 +08:00
@Noicdi #41 对我个人而言感觉并没有增加太多的安全性，又降低了一些便利性。
如果只有个别网站特殊处理并且每个网站不一样，那就是降低了便利性，提升的是 bitwarden 泄漏后的安全； 如果特殊处理都一样，那便利性和安全性基本没什么变化，和不做特殊处理差不多； 所以我现在就完全只用 1password |
 |
52
iwdmb 2023-11-08 00:46:57 +08:00
Tailscale
|
 |
53
body007 2023-11-08 11:05:13 +08:00
@YangWaleed #38 我的规律就是网址中间夹的那部分，例如：www.<pass>.com ，我还会首字母大写，以及太长了只用单词首字母。后缀有年份，每年用的时候发现年份不对就改一次密码。
|
 |
54
lm930129 2023-11-08 11:14:46 +08:00
@owwo 估计你安卓是因为证书的问题，安卓要求要有 fullchain 证书，如果在部署的时候，用 nginx ，没生成 fullchain 证书的话，安卓会报错，要求你安装证书。
|
|
55
YangWaleed 2023-11-08 20:26:48 +08:00
@body007 #53 我个人觉得健壮的密码就是单纯的随机，密码管理软件帮助管理这些随机密码。
在这之上增加任何有规律的内容都提升不了太多的安全性。靠人肉记忆的规律内容总会被找到规律。 如果担心密码库泄露，那不如用两个完全隔离的密码管理软件，每个只存半段密码。但这样牺牲的就是便利性了 |
 |
56
libook 2023-11-09 16:00:34 +08:00
我是在外面的时候用 vpn 连上家里的网络环境，然后用访问本地局域网的方式访问家里的服务。
除了 vpn 还可以用带认证的代理协议，比如 vmess 、ss 。安卓上可以用 tasker 在连上或者断开家里 wifi 的时候自动开启或关闭 vpn 、代理。 这样我家里所有服务全都隐藏在 nat 里面，除非我 vpn 或路由器被攻破了才会暴露在外面。 |
|
57
libook 2023-11-09 16:02:24 +08:00
我个人觉得 vaultwarden 本身的安全加密已经做得挺好了，这样反而最大的安全问题是数据完整性问题，也就是怎么备份密码数据的问题。
|
 |
58
72MpQOSsJhyLs88N 2023-11-10 21:31:58 +08:00 via iPhone
@lekai63 这不是跟只要你家大门比邻居家的结实就行了一样吗？网络上大多都是脚本小子找弱密码的，只要保持最新版本几乎无风险吧。普通人有何德何能值得顶级黑客定向攻击？
|
 |
59
benjaminliangcom 353 天前
@ZhiyuanLin #6 bw 的客户端似乎不支持 mtls https://github.com/dani-garcia/vaultwarden/discussions/2267
|
 |
60
ciki 108 天前
我在 nas 上自建的，现在 nas 坏了，一堆设备上的服务全部宕机
|
Select Language