把所有密码交给一个 App,真的不是疯了吗?主密码与加密保险箱的数学底牌
先说结论
一个设计合格的密码管理器,并不是“替你记住一张明文密码表”,而是替你保管一个加密保险箱。主密码也不是直接打开每个网站密码的万能钥匙,它更像制造钥匙的原料:设备先把它送进一个故意很慢的密钥派生函数,再得到能够解开保险箱密钥的派生密钥。服务器通常只负责保存和同步密文,真正的解密发生在你的设备上。
所以,把所有密码放进密码管理器,并不等于把所有鸡蛋毫无保护地放进同一个篮子。更准确的说法是:你把原来散落在几十个网站、浏览器、便签和大脑里的弱密码,换成了一个重点防守的主入口,以及几十个互不相同、随机生成的强密码。

图:原创配图。一个主密码负责解锁加密保险箱,保险箱里保存的是每个网站各不相同的随机凭据。
很多人第一次听说密码管理器时,都会本能地问:
“它要是被黑了,我所有密码不就一起完了吗?”
这个担心完全合理。毕竟在日常生活里,把所有现金、房产证和银行卡都塞进同一个箱子,听起来就是在给小偷准备大礼包。
但数字世界里有一个反直觉的地方:**同一个箱子,可以既是风险集中点,也可以是安全放大器。**关键不在“集中”两个字,而在于箱子里装的是明文还是密文、钥匙在哪里生成、猜一次钥匙需要付出多少成本,以及你是否还在其他地方重复使用同一把钥匙。
这篇文章不推荐某一个具体品牌,而是拆开密码管理器背后的共同数学原理:主密码、盐值、KDF、AES、认证标签、零知识同步,以及最容易被宣传语忽略的失守边界。
为什么不用密码管理器,反而更容易“一锅端”
普通人的真实密码习惯,通常不是“每个网站一个独立的 20 位随机密码”,而是下面几种组合:
- 一个常用密码走天下;
- 常用密码后面加网站缩写;
- 名字、生日、手机号片段加一个感叹号;
- 浏览器、聊天窗口、便签和表格里各存一份;
- 为了记得住,把重要网站和普通网站设成同一个密码。
这会产生一种非常危险的连锁反应:某个小网站安全做得差,数据库泄露后,攻击者拿着你的邮箱和密码,自动去尝试邮箱、网盘、购物、社交和办公系统。这叫凭据填充。攻击者不需要破解其他网站,只需要赌你“图省事,重复使用”。

图:密码复用像用绳子把所有多米诺骨牌绑在一起。每个网站使用唯一随机密码,才能把绳子剪断。
NIST 的数字身份指南明确要求服务允许密码管理器和自动填充,并指出带有密码生成器的密码管理器,会提高用户选择更强密码的可能性。它还强调,不同服务使用不同密码,可以避免一个站点泄露后引发凭据填充。

真实截图:NIST SP 800-63B 页面,截图于 2026 年 7 月 29 日。
密码管理器最重要的价值,其实不是“帮你记忆”,而是让你终于可以做到两件人脑很不擅长、计算机却很擅长的事:
- 为每个网站生成独一无二的随机密码;
- 在需要时准确取回,而不用把密码简化成人能背下来的套路。
它到底保存了什么
把密码管理器想成银行保险库容易产生误解,因为银行工作人员理论上能打开某些保险箱。更准确的比喻是:
你先在家里把日记写成一种只有你能还原的乱码,再把乱码复印件交给仓库保管。仓库知道你什么时候来过、文件有多大、可能属于哪个账户,但仓库拿到的正文仍然是一团密文。
一个典型密码保险箱会包含:
- 网站地址、用户名和密码;
- 安全备注、银行卡信息或身份字段;
- 密码生成器生成的随机凭据;
- 用于检测篡改的认证数据;
- 盐值、KDF 参数、版本号等解密所需的公开参数。
这里必须区分两件经常混为一谈的事:
登录某个网站时,网站一般只需要验证你的密码是否正确,所以适合保存不可逆的密码哈希。密码管理器却必须在自动填充时取回原密码,因此保险箱内容必须使用可逆加密。
OWASP 的密码存储指南也强调:普通网站验证用户密码时,应该使用 Argon2id 等慢哈希,而不是把密码加密后保存;只有确实需要还原原文的特殊场景,才需要加密。密码管理器正是这种必须取回原文的特殊场景,但它会把“验证主密码”和“加密保险箱内容”分成不同层处理。

真实截图:OWASP Password Storage Cheat Sheet,截图于 2026 年 7 月 29 日。
主密码不是直接拿去加密所有数据
如果软件直接把你输入的主密码当 AES 密钥,会有很多问题:密码长度不固定、人的选择有偏好,而且攻击者可以高速尝试常见词。
成熟设计会先做一层“加工”:
主密码 + 盐值 + KDF 参数
↓
密钥派生函数(Argon2id / PBKDF2 等)
↓
派生密钥
↓
解开随机生成的保险箱密钥
↓
用保险箱密钥解密每条记录

图:主密码更像“制造钥匙的原料”。真正负责批量加密数据的,通常是随机生成的对称密钥。
为什么中间还要放一个随机的保险箱密钥?因为这样更灵活:
- 修改主密码时,不必重新加密保险箱里的每一条记录;
- 可以只重新保护保险箱密钥;
- 分享、组织空间、设备密钥和恢复机制可以建立独立的密钥层;
- 每条记录还可以继续使用自己的随机密钥,缩小单个密钥的影响范围。
不同产品的密钥树并不完全相同,算法组合也会变化。以 Bitwarden 当前公开白皮书为例,它说明客户端在本地生成和管理加密密钥,保险箱数据离开设备前就已经加密;单条保险箱记录会由随机 Cipher Key 加密,再由用户或组织的对称密钥保护这个 Cipher Key。

真实截图:Bitwarden Security Whitepaper,截图于 2026 年 7 月 29 日。本文引用它作为公开实现案例,不构成品牌推荐。
KDF 为什么故意让你的电脑变慢
KDF 是 Key Derivation Function,也就是“密钥派生函数”。它最重要的设计目标之一,听起来很奇怪:故意让计算变慢、变贵。
可以把它想成小区门口的一台重型面粉机。
你每天回家只需要磨一次面粉,等半秒或一秒并不痛苦;小偷却想在一晚上试几千万袋“候选小麦”。如果每一袋都必须占用一大块内存、转很多圈、消耗时间和电力,小偷的成本会迅速膨胀。

图:合法用户只计算少数几次,攻击者必须为每个候选主密码重复支付成本。
常见 KDF 包括 PBKDF2、scrypt 和 Argon2id:
- PBKDF2 主要通过大量重复计算增加时间成本,兼容性很好;
- scrypt 同时要求计算和内存,降低专用硬件的大规模并行优势;
- Argon2id 是现代常见选择之一,能配置内存、迭代次数和并行度,兼顾对 GPU 破解与部分侧信道风险的防御。
Bitwarden 的 KDF 文档解释了它提供 PBKDF2 与 Argon2id 两种选择,并公开了默认参数及参数增大对运行时间、内存和线程的影响。

真实截图:Bitwarden Encryption Key Derivation 文档,截图于 2026 年 7 月 29 日。
这里有一个经常被误解的重点:**KDF 不能把“123456”变成好密码。**它只能让攻击者猜每一次都更慢。如果答案本来就在攻击字典的前几百名,再慢的门也只是晚几秒被撞开。
盐值不是调味料,而是每个人不同的跑道编号
盐值 Salt 通常不是秘密,也可以和密文一起保存。它的作用不是增加一个“隐藏密码”,而是保证相同主密码经过 KDF 后,不会得到完全相同的结果。
假设全班同学都把储物柜口令设成 summer-holiday。没有盐值时,攻击者算一次结果,就能同时比对所有人的柜子;加入每人不同的随机盐值后,即使口令相同,每个人的结果也不同,攻击者必须逐个重新计算。
盐值主要解决两个问题:
- 阻止预先计算好的彩虹表直接复用;
- 阻止攻击者一眼判断哪些用户使用了相同密码。
但盐值并不需要藏起来。它像赛道编号,真正的安全仍然来自主密码搜索空间和 KDF 成本。
AES-256 到底有多大
密码保险箱通常使用成熟的对称加密算法,例如 AES-256,或其他经过广泛分析的认证加密方案。AES-256 的密钥空间是 2^256。
这个数字大约有 78 位十进制数字。不要把它理解为“攻击者需要等 256 年”,而要理解为:即使每秒尝试极其夸张的次数,直接穷举一个真正随机的 256 位密钥,仍然远远超出可行范围。
因此,攻击者通常不会傻乎乎地直接穷举 AES 密钥。他会攻击更便宜的地方:
- 猜你的主密码;
- 偷已经解锁设备里的明文或密钥;
- 做一个长得很像的登录页面骗你输入;
- 利用浏览器扩展、剪贴板或键盘记录器;
- 针对恢复流程和第二因素下手。
换句话说,保险库钢板通常不是最薄的地方,人的习惯和终端环境才是。
加密还不够,必须能发现密文被动过
只加密、不校验完整性,就像把信写成暗号,却没有在信封封口上盖章。小偷也许读不懂内容,但可能悄悄调换某些字节,让解密结果发生变化。
因此安全设计还需要认证:
- 有的方案使用 AES-CBC 加 HMAC;
- 有的方案使用 AES-GCM 或 XChaCha20-Poly1305 等认证加密;
- 解密前或解密时验证认证标签,发现数据是否被篡改。
Bitwarden 当前白皮书公开描述了 AES-CBC 256 位加密与 HMAC 认证的组合。这里的重点不是押注某一个算法名字,而是确认产品使用经过公开分析的标准方案,并且同时保护机密性和完整性。
“零知识”到底是谁不知道什么
“零知识”是密码管理器最容易被说成魔法的词。
在密码管理器语境中,它通常表示:服务商保存的是客户端加密后的保险箱数据,主密码和可直接解密保险箱的关键材料不以明文交给服务端;服务商的员工不能像查询普通数据库字段那样直接读出你的密码。

图:设备本地加密,云端同步密文,另一台受信任设备取得密文后再在本地解密。
这不等于服务商“什么都不知道”。它可能仍然需要处理部分管理数据,例如账户邮箱、订阅状态、设备记录、登录时间或保险箱条目数量。不同产品收集的元数据不同,应该阅读其隐私政策和安全白皮书。
它也不等于网页客户端永远绝对安全。Bitwarden 白皮书明确提醒,网页客户端依赖 HTTPS 连接交付代码;如果攻击者能篡改交付给浏览器的客户端,就可能提供恶意客户端。这也是为什么高价值账户需要同时考虑软件更新、代码签名、扩展权限和终端防护。
云端保险箱泄露,攻击者会拿到什么
假设最坏情况发生:攻击者偷到了某个用户的加密保险箱、盐值和 KDF 参数。
如果设计和实现没有其他漏洞,他通常不会立刻看到你的邮箱密码,而是得到一道可以离线反复答题的数学题:
- 选一个候选主密码;
- 加上对应盐值;
- 按相同 KDF 参数计算;
- 尝试解开受保护密钥或验证结果;
- 不正确就换下一个候选词。
在线登录时,服务端可以限速、封禁 IP、要求验证码;拿到密文后,攻击者可以在自己的机器上离线尝试,不再受登录接口限速。因此,云端泄露后的安全强度,主要取决于主密码有多难猜,以及每次猜测有多贵。

图:KDF 是乘法器,不是复活术。弱主密码的搜索空间太小,仍可能被字典攻击快速命中。
可以用一个简化公式理解平均破解时间:
平均时间 ≈ 候选空间 ÷ 每秒猜测次数 ÷ 2
除以二,是因为平均不需要试完整个空间。真实攻击还会按人类习惯排序,优先尝试泄露密码、键盘规律、姓名、年份和常见变体,所以“看起来有 12 位”不一定等于拥有 log₂(字符集^12) 的随机熵。
真正随机选择的六个 Diceware 风格词,理论搜索空间可以达到约 77 位;但如果你自己挑的是一句名言、歌词或固定句式,实际熵会低得多。长度重要,随机生成方式同样重要。
为什么密码管理器敢“记住全部”,你却不能忘记主密码
零知识设计的代价是残酷的:如果服务商真的拿不到你的解密密钥,它通常也无法像普通网站那样“把旧密码发给你”。
不同产品会提供不同恢复机制:
- 已登录设备上修改主密码;
- 紧急联系人或家庭恢复;
- 企业管理员账户恢复;
- 恢复码、设备密钥或可信设备;
- 删除账户后重新开始。
恢复机制越方便,就越需要仔细理解它是否引入新的解密路径。安全不是“恢复越少越好”,而是恢复路径必须透明、可审计、受第二因素和等待期保护。
真实产品如何让用户配置保险箱保护
开源密码管理器 KeePassXC 的用户手册展示了数据库安全设置:用户可以修改数据库密码,并叠加 Key File、硬件密钥等额外保护。它代表另一类架构——保险箱文件可以完全由用户自己保存和同步,而不必依赖某个厂商云端。

真实截图:KeePassXC 官方用户手册中的数据库安全界面,截图于 2026 年 7 月 29 日。
本地文件型和云同步型密码管理器各有取舍:
| 方案 | 优点 | 需要你承担的责任 |
|---|---|---|
| 本地保险箱文件 | 数据位置可控、可离线、厂商依赖少 | 自己备份、同步、处理冲突和设备丢失 |
| 端到端加密云同步 | 多设备方便、同步简单、恢复与共享能力丰富 | 信任客户端实现、账号体系和服务可用性 |
| 浏览器内置管理器 | 使用门槛低、自动填充顺滑 | 跨生态能力、安全设置和导出能力因平台而异 |
“本地”并不自动等于安全,“云端”也不自动等于不安全。没有备份的本地保险箱,可能被一次硬盘损坏摧毁;设计良好的端到端加密云同步,即使服务器泄露,攻击者也仍然需要破解用户保险箱。
密码管理器会在哪些地方失守
任何宣传“用了密码管理器就绝对安全”的说法都不专业。它能显著改善密码复用和弱密码问题,但不能消灭所有攻击面。

图:保险箱保护静态秘密,但钓鱼、恶意软件、已解锁设备和恢复流程仍然可能绕过保险箱。
主密码太弱
这是最直接的风险。把常用密码升级成 常用密码+网站名,仍然不是随机主口令。主密码必须独立、唯一、足够长。
设备已经中毒
当保险箱处于解锁状态时,合法应用必须能得到明文并完成自动填充。拥有足够权限的恶意软件也可能截屏、记录键盘、读取剪贴板或注入浏览器。加密主要保护“静止的数据”,不能让一台完全失陷的终端继续可信。
钓鱼骗走主密码
密码管理器的域名匹配自动填充可以降低钓鱼风险:假网站域名不匹配时,扩展通常不会自动填充。但如果用户主动复制粘贴主密码,或者安装了恶意客户端,仍然可能中招。
保险箱一直不锁
电脑离开座位、浏览器扩展长期解锁、手机没有可靠锁屏,都等于把保险库门敞开。应设置合理的自动锁定时间,并优先选择“锁定”而不是长时间保持明文可用。
第二因素和恢复资料丢失
MFA 能保护在线登录,却通常不能提高被盗保险箱的离线加密强度;它们防的是不同问题。恢复码如果和主密码一起放在同一台未加密设备上,也会形成单点故障。
怎样设计一条真正靠谱的主口令
最实用的方向不是强迫自己背一串大小写、符号和数字乱炖,而是使用足够长、随机生成、从未复用的多词口令。

图:长度、随机性、唯一性和恢复能力缺一不可。
建议遵循下面的原则:
- 使用密码管理器或可信随机方法生成 5–7 个互不相关的词;
- 不要使用名言、歌词、地址、学校、家人姓名和年份;
- 不要把这条主口令用于邮箱、电脑登录或任何其他网站;
- 第一次设置后,在安全环境中多输入几次形成肌肉记忆;
- 把应急恢复资料写入纸质或离线加密介质,放到与设备不同的位置;
- 为密码管理器账户启用独立的 MFA 或 Passkey;
- 让保险箱在锁屏、浏览器退出或短时间闲置后自动锁定。
不要把示例口令直接拿去使用。任何公开出现在文章里的字符串,都已经进入攻击者字典。
选择密码管理器时,不要只看“用了 AES-256”
算法名称只是起点。选型时更应该检查完整系统:
- 是否公开安全设计、密钥派生和加密流程;
- 是否支持现代 KDF,并允许提高参数;
- 是否采用认证加密或等价的加密加认证组合;
- 是否在客户端完成关键加解密;
- 是否接受独立安全审计,漏洞响应是否透明;
- 是否能导出数据,避免被单一厂商永久锁定;
- 是否支持自动锁定、MFA、Passkey、恢复码与紧急访问;
- 浏览器扩展权限是否合理,更新渠道是否可信;
- 元数据收集范围和隐私政策是否可以接受。
CISA 的公众安全材料也把使用密码管理器列为强密码实践的一部分。它的页面已经标记为归档内容,但“为每个账户生成并保存强密码”的核心建议仍具有参考价值。

真实截图:CISA Use Strong Passwords 页面,截图于 2026 年 7 月 29 日;页面自身带有归档提示。
一个更诚实的风险结论
密码管理器确实会制造一个高价值目标:主密码、解锁中的设备和客户端更新链都值得攻击者重点关注。
但不用密码管理器并不会让风险消失,只会把风险变成更隐蔽、更难管理的形式:密码复用、弱口令、忘记后重置、便签泄露、浏览器散落数据,以及无法及时更换泄露凭据。
合理的比较不是:
“密码管理器有没有风险?”
而是:
“在同一个真实的人类记忆能力下,密码管理器方案和手工记忆方案,哪个让攻击者付出的总成本更高?”
对绝大多数人来说,答案是:一个强而唯一的主口令、一个经过公开审查的密码管理器、每站唯一随机密码,再加 MFA/Passkey,比重复使用几组人脑密码安全得多。
常见问题
密码管理器公司倒闭了怎么办
提前确认能否导出标准格式或加密备份,定期做离线备份。不要把导出的明文 CSV 长期留在下载目录;导出完成后应立即转入加密存储或安全删除。
云端被黑后,我需要立刻修改所有密码吗
要看事件范围:是管理数据泄露、加密保险箱被复制、客户端更新链受影响,还是明文已经暴露。应先阅读官方事件说明,更新客户端,提高 KDF 参数和主密码强度,并优先更换邮箱、金融、云平台和身份恢复账户。不能用一句“用了 AES-256 所以没事”代替事件分析。
主密码可以存在密码管理器里吗
不能把唯一的主密码只存在它自己锁住的保险箱里。可以保存一份纸质应急副本,或放在另一套独立加密和访问控制体系中。
生物识别是不是代替了主密码
通常不是。指纹或面容识别更多是在本机授权系统释放一个受硬件或操作系统保护的密钥。重启、超时、策略变化或设备迁移后,仍可能需要主密码。
MFA 能阻止离线破解吗
一般不能直接阻止。MFA 主要保护在线登录;攻击者如果已经拿到可离线验证的加密保险箱,核心防线仍是主密码强度和 KDF。两者都要用,因为它们防守的是不同入口。
Passkey 出现后,密码管理器会消失吗
不会很快消失。Passkey 仍需要安全保存、同步、备份和跨设备使用;密码管理器正在从“密码仓库”逐渐演变为“数字身份与凭据仓库”。在很长一段时间里,密码、TOTP、恢复码、Passkey 和安全备注会共存。
最后一句话
密码管理器敢记住你所有密码,不是因为它自信“永远不会被黑”,而是因为它把问题从“人类能不能记住几十个强密码”,转换成了一道更可控的工程题:
用一个足够强的主口令,通过昂贵的 KDF 派生密钥,在设备上解开经过认证保护的加密保险箱;让服务器只负责搬运密文,让每个网站使用独立随机密码,并把终端、恢复和第二因素作为另一层防线。
真正需要相信的不是某句广告,而是公开的密码学设计、可验证的客户端行为、持续的安全审计,以及你自己是否守住了那条唯一的主口令。
参考资料
- NIST SP 800-63B: Authentication and Authenticator Management
- OWASP Password Storage Cheat Sheet
- Bitwarden Security Whitepaper
- Bitwarden Encryption Key Derivation
- KeePassXC User Guide
- CISA: Use Strong Passwords
本文用于解释通用安全原理,不构成针对特定产品的安全背书。产品实现、默认参数和恢复机制会更新,部署或迁移前应重新核对最新官方文档。