目录

林间·栈笔

密码放在云端到底安不安全

文章拆解1Password安全设计:客户端本地生成128位Secret Key永不上传,与主密码经PBKDF2/HKDF派生后构成加密密钥,库体用AES-256-GCM加密,服务器被攻破也无法解密。对照LastPass因仅凭主密码导致备份库被离线爆破。2023年Okta事件未泄露用户库,只波及支持系统元数据。两步验证仅防登录取密文,挡不住设备被控或实时钓鱼;真正弱点在主密码强度与设备安全。建议采用随机词主密码、硬件密钥、独立验证器,打印应急包并接受官方无法恢复。结论:云端密码库比人脑记忆可靠,但需理解信任边界。

写于北京市,天气晴 · 5.1°C,心情惬意 ☕。

  • 55 次阅读
  • 阅读时长
  • 1 条评论

「你把所有密码都存在一个网站上?」

这句话我被问过不止一次,语气都差不多,像是在确认我是不是对安全这回事有点不上心。

我一般反问:那你的密码存在哪儿。答案一半是「脑子里」,一半是「常用的那几个差不多」。后面这句才是真正的问题。

先把两个问题拆开

「云端安不安全」这句话里混了两件事:密码学,和信任。搅在一起就只能吵架。

拆开看是四个问题。前三个决定最坏情况有多坏,第四个决定最坏情况有多难堪。

  • 云上存的是密文还是明文?
  • 厂商自己有没有能力解密?
  • 有没有一把钥匙根本不放在服务器上?
  • 出事时丢的是库里的内容,还是账号元数据?

密码管理器这二十年大致走了三步。最早是把密码加密存在一个本地文件里,同步靠自己拷 U 盘。后来改成主密码派生密钥、密文放云上,省事,但整个库的安全就系在主密码一根绳上,服务器被端走,剩下的问题只是「这个主密码够不够难猜」。再往后是加第二把钥匙,一把由设备生成、永远不上传的随机串。

1Password 是这条路上走得最早的,也是被讨论最多的。

1Password 具体在做什么

注册的时候,客户端在本地生成一个 128 位的 Secret Key,看起来是一串分组的字符,A3 开头。这东西不上传,不参与网络传输,只存在你的设备和那张应急包纸上。

真正用来加密的密钥,是这么一步步凑出来的:

PBKDF2-HMAC-SHA256,迭代 650,000 次,salt 是邮箱,得到 256 位。HKDF-SHA256 展开成 256 位,salt 是账户 ID。合成 Account Unlock Key(AUK)。AUK 再拆成加密密钥与签名密钥,库内容用 AES-256-GCM 加密。

登录走 SRP 协议,服务端存的是一个验证值,主密码和 Secret Key 都不需要传过去。于是服务器上到底有什么,可以这么分:

服务器上有的

打不开的加密库、SRP 登录验证值、邮箱、IP、设备列表、账单信息。

服务器上没有的

128 位 Secret Key,以及你的主密码。这两样从头到尾没上去过。

假设明天整排服务器被搬走。攻击者拿到的是密文,缺那 128 位随机值。主密码哪怕只有 40 位熵,加起来也接近 170 位,这个量级的暴力破解不在现实范围内。不是「很难」,是没有可行路径。

上面这些参数和流程,是 1Password 自己写在白皮书里的。代码不开源,你能验证的只有黑箱行为和第三方审计(Cure53、ISE 做过评估,还有 SOC 2)。 设计讲得通,不等于你能亲手检查。这是选闭源产品的固定代价,绕不过去。

2023 年那次事故,到底丢没丢东西

事情本身挺荒唐的。一名 IT 同事找 Okta 支持排查问题,按要求上传了一个 HAR 文件,也就是浏览器导出的网络请求记录。问题是这份记录里带着当时登录会话的 cookie。

一名 IT 同事找 Okta 支持排查问题,按要求上传了 HAR 文件。这份浏览记录里带着当时的登录会话 cookie。1Password 收到一封「你申请了管理员名单」的系统邮件,没人申请过,当天终止活动并开始调查。Okta 确认自身支持系统被入侵,1Password 确认这次事件源头在那边。官方结论:用户数据、库内容、生产系统均未被访问。Okta 后来承认攻击者下载了包含全部支持系统用户姓名与邮箱的报告。

要分清这里被碰到的是什么。存密码库的系统和管员工登录的系统是两套东西,被端的是后者的门禁。官方后来公布的结论是:没有任何用户数据、库内容或生产系统被访问。

但这事也不是没损失。Okta 那边的调查结论是,攻击者下载了一份包含所有支持系统用户姓名和邮箱的报告,后来还公开承认了。元数据层面确实有东西流出去,只是这些东西本来就大半是公开的。

我的看法是,这次事故暴露的不是密码学,是支持流程。让客户上传带 cookie 的 HAR 文件,本身就是一个坑,那年 Cloudflare 后来开源了一个工具专门洗这种文件。边界守住了,但守得挺难看。

拿 LastPass 做个对照

同样是「云被端了」,2022 年 LastPass 的结果完全不同。攻击者拿到了备份存储里的加密库,那批数据里有大量用户的保险库。

区别不在「上不上云」,在于服务器上那把锁是不是完整的。同样是服务器被搬空,一个丢的是内容,一个丢的是一堆打不开的文件。

两步验证到底管什么

两步验证保护的不是解密,是「登录并且把密文取走」这一步。

这里有个容易搞混的点,值得慢慢说。

想一下最惨的情况。有人同时拿到了你的主密码和 Secret Key,比如应急包被拍照、旧手机没清、钓鱼页面套走了一部分。这种情况下他其实已经能离线解密了,但前提是他手上得有密文。拿密文要登录。两步验证就卡在这一步上。

所以它不是心理安慰。分两头说更清楚:

远程撞库,以及密码泄露之后的账号接管。

钥匙凑齐了但差一张门禁卡的情况:有主密码和 Secret Key 就能离线解密,可前提是手上得有密文,拿密文要登录。它卡的就是这一步。

设备被控制——库已经在你的内存里解开了。你人在座位上被人借电脑用。

TOTP 被实时钓鱼:假页面收走六位数,三十秒内用掉。

以及最常见的,把验证码也存进同一个库,第二因素跟第一因素住一间屋。

还有一点:1Password 不能给自己当验证器,官方文档写得很直白。有条件就上硬件安全密钥,WebAuthn 那套东西钓鱼站拿不到签名;没条件就用独立的验证器 App,别用短信。

真正的弱点还是人和设备

这套系统里最难攻的位置,一直是主密码的强度和设备本身。

四个随机词,比八位大小写数字强得多。

好记、好输、不容易错。比如「扳手 柿子 台灯 凉皮」这种,熵就过了 66 位。

八位大小写加数字:46 位熵,破解成本约 5.8 万美元。

四个随机词加分隔符:66 位熵,成本到了几百亿美元。

五个随机词:84 位熵,成本是 $14,000,000,000,000,000。

这张表算的是主密码单独被爆破的情形,没把 Secret Key 算进去。所以实际更安全,但不代表主密码可以随便设。

设备这头更实际。全盘加密、屏幕锁、自动锁定时间调短一点,浏览器扩展只在已保存的域名上自动填充。这些做完,比纠结用哪个密码管理器有用得多。

邮箱是所有账号的万能钥匙,它自己的两步验证优先级最高,别拿它去试新功能。

定期导出一份库,不是为了防谁跑路,是为了被锁在门外的时候还有条路。导出文件是明文的,用完记得删。

打印一份放抽屉,别拍照存相册,也别塞进云笔记。 同时要接受另一件事:**丢了 Secret Key 又忘了主密码,官方也救不了你**。这是设计的一部分,不是缺陷。

还有一个跟安全无关、但很多人绕不开的点:1Password 是加拿大公司,机房在加拿大、美国、德国,国内访问不一定顺。这属于可用性问题,不影响加密强度,但会影响你到底能不能用下去。

我的结论

把密码放在云端,比放在脑子里安全得多。人脑能记住的强密码就一两个,剩下的必然复用,而复用是这十几年大规模泄露里最常见的导火索。

云的风险是真的,但被端走的时候你丢什么,取决于当初设计的人有没有把一把钥匙留一份在你手上。1Password 留了,LastPass 没留全,这就是同样的「云端」两个字下面最要命的差别。

两步验证开着,优先硬件密钥,其次独立 App。但别把它当最后一道墙。真正的墙是那把不在服务器上的钥匙,加上你还想不想得起主密码。

白皮书里写清了全部派生流程,想自己核对的可以点上面那张卡片。2023 年那次事件的原始报告在 1Password 博客上,标题是 Okta Support System incident and 1Password。

如果连这些都不愿意信,那就离线:KeePassXC 加自己的同步方案。代价是冲突、备份、丢文件都得自己管,大多数人一周就放弃了。我试过。

那年今日11 月 10 日

    评论区

    友链提交
    请认真填写以下信息,谢谢!

    博客信息

    林间拾语
    (请填写完整的网址,例如:https://www.example.com)
    (贵站展示本站链接的页面地址,一般是友链页面,填写后将自动验证友链关系有效性)
    (用于抓取文章)
    (用于接收通知)