证明您的浏览器并非保管库。

Chrome（以及所有 Chromium 浏览器）

Chrome 将登录信息存储在 SQLite 数据库中——Login Data，表 logins，列 password_value——并使用 AES-256-GCM 加密。AES 密钥存放在 Local State 中，由操作系统“保护”：Windows 上的 DPAPI，macOS 上的登录钥匙串，Linux 上的 gnome-keyring/kwallet（或纯文本）。

您可以自己阅读——代码是开源的。在 Chromium 中搜索标记封装密钥的常量：os_crypt 中的 kDPAPIKeyPrefix。该密钥经过 DPAPI 封装、标记并存储，然后通过一次调用解包，而这道防线对您毫无保护作用：

const char kDPAPIKeyPrefix[] = "DPAPI";

CryptUnprotectData(&intermediate, /*ppszDataDescr=*/nullptr,
                   /*pOptionalEntropy=*/nullptr, nullptr, nullptr, 0, &output);

没有第二道机密，没有密码，没有提示。CryptUnprotectData 会将密钥交还给您的会话中运行的任何进程——这正是 DPAPI 文档中描述的威胁模型：如果它以您的身份运行，它就是您。攻击者的全部工作只需三行代码：从 Local State 读取密钥，解包它，然后对 Login Data 中的每一行进行 AES-GCM 解密。信息窃取恶意软件多年来一直正是这样做的。

“设备端加密”同样无法拯救您

Google 的解决方案是一个 6 位数 PIN 码，用于加密您同步的保管库。2026 年 5 月，Phishu 的研究人员展示了这种保护有多么薄弱。一个逼真的伪造 Google 登录页面——中间人钓鱼攻击——会捕获会话和该 PIN 码，而这个 PIN 码就是同步帐户中每个密码和通行密钥的主密钥。借助它，攻击者可以将自己的设备加入您的 Google“安全域”，整个保管库会直接同步给他们——一步即可完全接管。

设计缺陷：Google 允许设备仅凭 6 位数 PIN 码即可加入，无需您已有设备的批准。

Firefox

Firefox 将登录信息保存在 logins.json 中，将密钥保存在 key4.db 中，由 NSS 的“Secret Decoder Ring”解密——这也是开源的：security/nss/lib/pk11wrap/pk11sdr.c。如果您设置了主密码，该密钥就会用它来密封。

默认情况下，您并没有设置——因此该密钥是用空字符串密封的，并且存储的“password-check”值确认空密码可以解密它。从您的配置文件中复制两个文件（key4.db + logins.json），让 NSS 或开源的 firepwd.py 指向它们，它们就会被解密。一把钥匙贴在门上的锁算不上锁。