不只为了省钱：开源密码管理器可用性报告

A version of this article appears on Dec. 31, 2023 on SSPAI as a member-only post. Learn more or subscribe

The article is permitted to be self-archived in the version as originally submitted for publication on the author’s personal website under CC BY-NC 4.0 pursuant to § 5.2(b) of the SSPAI Fellowship Contributor Agreement.

TL;DR

• 尽管面临一些合理质疑，1Password 对于大多数用户仍然是最省心的选择，定价相对于提供的服务水平也是合理的。如果你纯粹因为价格因素而想逃离 1Password，那么你最好的选择可能是继续使用 1Password。
• 对于有一定动手能力的用户，用 Bitwarden 或 KeePass 等开源方案替代 1Password 是可行的，并且使用体验相比前几年已经有所改善。相对而言，KeePass 的初始配置门槛更低，Bitwarden 则在功能上更为完善。

在密码管理领域，1Password 的领导地位毋庸置疑。但随着时间推移，对它的质疑和顾虑也逐渐积累：决绝地转向订阅制、云端存储和 Electron「套壳」开发，惹恼了不少老用户；两次接受风投融资、大力拓展商用业务，也引发了对其偏离「群众路线」的担忧。

于是，「有什么好的 1Password 替代品」自然成了很多用户关心的问题。在众多选项中，以 KeePass 和 Bitwarden 为代表的开源方案尤其受极客用户青睐。

然而，如果你真的听从一些推荐，准备从 1Password 迁移到这些开源方案，就会发现并非易事；开源的「自主」也意味着需要「自助」。即使愿意花这个功夫，能否完整迁移现有数据、能否延续之前习惯的操作，也是令人犹豫的因素。

更何况，在密码管理这件事上，任何纯粹以省钱为导向的决策都是错误的，而「开源」光环本身并不足以为质量提供担保。

因此，本文的目的就是从安全性、便利性等角度出发，研究从 1Password 迁移到 Bitwarden 或 KeePass 的可行性究竟如何，并为有意尝试的用户提供一些提示和技巧。

开源选项知多少

开源密码管理工具数量不少，但 Bitwarden 和 KeePass 可能是为数不多能在口碑、功能、跨平台支持等多方面与 1Password 对标的。它们的密码存储机制正好分别类似于 1Password 转向云端前后的两种模式。

Bitwarden

Bitwarden 是一个相对年轻的项目，2016 年才问世，但凭借着不错的功能集和活跃的更新，已经积攒了一定的口碑。

和当前的 1Password 类似，Bitwarden 采用了中心化的 SaaS 架构：密码数据存储在服务端，客户端只负责读取。但 Bitwarden 服务端和客户端代码（绝大部分）都是开源的，官方还提供了服务端的 Docker 镜像，允许用户自行托管。

问题在于，这个官方版本包含组件众多、非常笨重，要求预留至少 2GB 内存和 12GB 硬盘空间，对于很多个人服务器来说负担过大。因此，当我们说「自建 Bitwarden」时，一般指的都是自托管社区开发、兼容原版 API 的轻量版本服务端 Vaultwarden¹，然后再与各平台的官方客户端搭配使用。Vaultwarden 在初代树莓派上也能跑得起来，对于当下大多数 NAS、VPS 自然不成问题。

KeePass

KeePass 的历史则悠久得多，从 2003 年底就一直存在。其架构也更为传统，类似于旧版的 1Password：没有服务端，所有数据存储在一个 KDBX 格式（其主体是经加密的 XML）的密码库文件中。²只要是能读写这个格式的工具，都可以充当 KeePass 的「兼容客户端」。事实上，由于原版 KeePass 只支持 Windows，界面和操作设计又极其古旧，兼容客户端才是更常见的选择。

因此，如果选用 KeePass，主要需要考虑的问题是 (1) 选什么客户端和 (2) 怎么同步密码库。具体选项将在稍后推荐。

顺带一提，KeePass 生态的协作文化堪称模范。你可以看到两个竞品客户端的开发者在 Reddit 用户「选谁好」的提问下「商业互吹」，或者为了一个拟议扩展格式友好探讨。在如今戾气渐长的开源社区，这样的氛围不多见。

安全与稳定性

安全稳定是密码管理软件的生命线。然而，这也是最令用户摸不着头脑、无从判断优劣的因素。如果只看各个产品的官方网站，给人的印象好像个个都是固若金汤、无懈可击。

我的建议是……忽略这些宣传。的确，如果仅从抵御暴力破解的能力看，只要用上足够长度的加密算法，效果基本都能过关。例如，本文讨论的 1Password、Bitwarden 和 KeePass 都支持 256 位 AES 加密，在设计结构和密钥长度上都能满足保护机密信息的需求。就算量子计算机明天就会普及，这也不是种一时半会能「撞开」的算法。³

但对密码管理器而言，暴力破解仅仅是诸多可能面对的威胁中的一部分。在这样一个由密码库、服务端和客户端等多个组件构成的系统中，每个组件都可能遭到攻击或出现故障，成为影响整个「木桶」的安全和稳定的「短板」。

不过，要列举各种潜在威胁并比较各个产品的防御能力，是比较困难的，本文的篇幅也不允许这么做。但我们可以换种思路：在信息系统中，「信任」——对他方行为的假设和依赖——是漏洞的根源，过度或错位的信任都会成为风险。因此，通过比较不同密码管理器都依赖于哪些「信任」，就可以方便地看出风险所在，以及判断是否可以接受。

下表就是基于这种思路的（高度简化的）比较，部分借鉴了以太坊创始人 Vitalik Buterin 的方法。每格中的分母表示该组件总共涉及多少提供方，分子表示仅当其中多少个提供方按期望方式运行时，系统才能无故障且安全地使用。例如，「1/1」表示「该组件只有一个提供方，且仅当该方按期望运行时，才能正常使用」。

说明和分析如下：

1Password

作为商业化产品，1Password 从服务端到客户端都是由开发商提供的，密码库也存储在开发商的服务器上，并且代码都是闭源。换句话说，只要 1Password 的代码或服务器出了什么岔子，倒霉的就是用户。

这就是最典型的「中心化」模式，对普通用户最省事，但重度依赖于对开发商的信任。

一个加分项是，自 2015 年开始提供云端服务以来，1Password 没有出现过重大的安全或宕机事故（尽管前两个月遇到一次有惊无险的风波）。当然，这只是一种资历，不能成为全盘信任的理由。

Bitwarden

与 1Password 的一条龙模式相比，（自建版）Bitwarden 最大的不同之处在于有多个提供方：客户端由 Bitwarden 官方提供；服务端和密码库存储的代码来自民间社区项目 Vaultwarden，由用户自行托管。

换句话说，这个系统中的「信任」非常分散。用户除了要信任 Bitwarden 和 Vaultwarden 的代码，还要信任自己用来托管这些代码的服务器。诚然，完全开源的代码减少了对「信任」的依赖程度，因为可以自己验证，而无需听信开发商的主张。但显然，绝大多数用户都没有条件和能力去审阅这些代码。

此外，受技术能力、消费级自建服务器的质量所限，自建系统的可靠程度实际上未必高于经过市场考验的闭源服务。（想想你有多少次因为瞎折腾失败，把 VPS 和树莓派抹掉重新来过。）因此，很难说自建 Bitwarden 在安全性上相比 1Password 有更大优势。

KeePass

这是最为「去中心化」的方案。其优点在于没有服务端需要信任，密码库存储和客户端都有丰富选择，可以同时使用、互为备份。缺点则也在于信任的分散：每引入一个存储方案和客户端，就意味着要多信任一个第三方的安全和稳定，而经验表明很多小型开源作品并不足以支撑这样的信任。

总之，开源并不意味着更安全。相反，如果配置不当，使用开源密码管理器反而会让自己暴露于更大风险之下。

当然，指出这点的目的也不是劝退，只是提示读者在选择时注意权衡利弊，并且做好相应的「功课」：如果选择 Bitwarden 方案，需要准备好尽量靠谱的自托管环境（例如运行稳定、性能充裕的 NAS 或云主机）；如果选择 KeePass 方案，则要尽量选择稳定的云存储和靠谱的客户端。

易用性

分析完了安全稳定这个前提，还要关注的是密码管理器本身是否「好用」。实际上，在很多观点看来，使用密码管理器之所以更「安全」，很大程度上是因为它通过减少用户的记忆负担，鼓励用户设置复杂（高熵）、不重复的密码。如果一个密码管理器复杂到让用户提不起使用意愿，以至于重新回到手动输入和重复使用弱密码的老路上，这种好处也就荡然无存了。

为此，下文会从多个角度比较 1Password、Bitwarden 和 KeePass 的易用性，并穿插一些配置使用方面的提示和建议，以方便读者的选择和探索。

跨平台支持

可能很少有什么类型的软件比密码管理器更需要跨平台支持了。在宣布 1Password 8 桌面版转向 Electron 这一受争议的决定时，开发团队的主要理由就是提高跨平台开发效率、减少平台间功能差异。

从结果来看，尽管还是有些 macOS 老用户对于被剥夺了原生界面版本比较介意，这么做确实让 1Password 支持的平台更多、设计的整体性更强了。从桌面系统到移动系统，从浏览器到命令行，你基本上不用担心 1Password 是否支持自己使用的平台，而且对于各平台原生功能的支持也非常及时。

Bitwarden

与之相比，Bitwarden 总体上做得也不错，在平台覆盖面、原生功能支持等方面与 1Password 是完全看齐的。但如果考虑上设计水平和用户体验，Bitwarden 的出品就要粗糙得多了。

例如，同样是基于 web 技术打包，1Password 8 的桌面版经过几轮迭代，在采用 Electron 的软件中已经算是水准很高。而 Bitwarden 无论是控件风格、动画质感还是操作手感，都仿佛停留在多年以前：设置界面没有独立窗口，而列表视图竟然连 Shift 多选这样基本的惯例交互都不支持，几乎泯灭了专门做个客户端的意义。移动版基于完全相同的设计和框架，体验也是类似。总之，最高的评价就是「捏着鼻子能用」。（好在密码管理器的交互频率不高，确实属于「捏着鼻子能用就行」的一类产品。）

KeePass

KeePass 方面的情况就更乱了。如上文介绍，原版 KeePass 只支持 Windows，而且并不值得推荐；其他平台则更是都靠第三方兼容客户端来覆盖。

此外，KeePass 官方页面虽然提供了一个兼容客户端列表，但其中大部分信息都已经过时。经笔者测试，以下是截至本文写作时在各平台推荐选用的客户端，供读者参考。如果列举了多个选项，排序方式是按推荐程度递减。

（其实试过的远不止这些，没有列出的基本都是存在重大功能不足或者停止维护。虽然可能勉强能用，但体验实在过差，就不一一列举浪费大家时间了。有兴趣的读者可以自行尝试。）

顺便一提，如果你是因为对 1Password 改用「套壳」框架不满而考虑其他选项，那么特别值得推荐的是 macOS/iOS 上的 Strongbox。虽然定价有点门槛，但它绝对是你见过最符合 Apple 设计规范的软件之一，「原生感」甚至超越以此闻名的旧版 1Password；而且以一己之力在 KeePass 的简陋地基上做出了获得了不输 1Password 的使用体验，可见功力了得。

初始配置难度

对于 1Password 这样的「全管理型」服务而言，其价格的一部分就是服务成本。而既然考虑 DIY 方案，动手环节自然免不了。但至于到底哪些方面要动手、动手到什么程度，Bitwarden 和 KeePass 确实存在不少差异。

Bitwarden

如前面所说，Bitwarden 的架构与 1Password 类似，都以服务端为中心。因此，如果决定自建 Bitwarden 服务，首先就要选择一个靠谱的托管位置。对于个人用户而言，家用 NAS、树莓派或者装有稳定发行版且访问条件好的云主机都可以考虑（内网设备需要配置内网穿透，但那不属于本文讨论范围）；至于那些经常用来折腾的设备，就不要拿来担此重任了。

部署流程方面，根据 Vaultwarden 项目 wiki 的说明，启动 Docker 容器并设置 HTTPS 证书即可（也可以用提供的 Docker Compose 样本一步到位）。⁴

部署完成后，在浏览器中访问服务器地址即可看到初始设置。这里，绝大多数选项都可以维持默认，唯一必须认真填写的是邮件服务器配置。这是因为 Vaultwarden 需要一个 SMTP 服务器来发送各种通知邮件，包括发送创建第一个账户所需的「邀请链接」（注意 Bitwarden 是一个多用户服务，刚部署时并没有用户）。

不过，这个邮箱本身并不需要自己托管，包括 Gmail 和 iCloud 等常见邮箱都可以使用，只要根据实际情况查找相关提供商的 SMTP 服务器信息，并且准备好专用密码（iCloud 邮箱之类的服务需要）即可。

走完初始设置并创建好账户后，从 Bitwarden 官方下载客户端，在登录时选择「自托管」服务器并填入地址即可。

最后，对于这种中心化服务，备份是必不可少的日常任务。一个好消息是 Vaultwarden 的所有文件都存储在一个目录下，即与其主程序同路径的 data 目录，因此备份和恢复都只要关注这一个位置即可。详细目录结构参见文档，结尾还提供了一些第三方脚本方便自动化。

KeePass

KeePass 没有服务端需要设置，但为了跨设备使用，仍然需要使用云盘来放置密码库。

这对于桌面系统没什么影响，因为文件系统是开放的，直接依赖云盘的客户端来同步密码库即可。对于移动端，上面推荐的 Strongbox、Keepassium 和 Keepass2android 都支持一系列常用的云存储选项，包括 Dropbox、Google Drive 和 OneDrive 等商业服务，以及 WebDAV、SFTP 等网络挂载协议，按照自己的喜好选择即可。

不过，在条件允许的情况下，即使在移动端，也最好使用外部同步应用提供的存储功能，而不是使用 KeePass 客户端内置的云存储支持（例如通过 iOS 的 File Provider 功能和 Android 上的 FolderSync 等应用挂载；过去介绍过的 Syncthing 也是很多进阶用户推荐的选择）。这是因为前者能更稳定地保持后台同步，并且更快适配相关 API 的不时变化。而且这些 KeePass 客户端都会在每次启动时试图访问挂载的云存储，从而严重拖慢启动速度。相比之下，外部同步会为密码库创建本地缓存，从而避免这一等待。⁵

此外，无论如何选择，核心标准都是稳定、靠谱，也不要忘了经常备份密码库文件。

数据可迁移性

对于每个考虑从 1Password 迁移到其他产品的用户而言，这可能都是最主要的顾虑。毕竟，没有人会想为了换个密码管理器，从头整理一遍注册过的几百个账户。

公平地说，1Password 的表现已经算比较大度。目前版本的 1Password 8 版本支持两种导出格式（文档），分别侧重于「完整」和「通用」两个目标：

• 1Password Unencrypted Export (.1pux): 这是默认的导出格式，取代了旧版采用的 1Password Interchange Format (.1pif)。1PUX 格式有比较完备的文档，根据其说明，1PUX 文件实质上是一个 ZIP 压缩包，其中以 JSON 格式存储了各项密码库信息，并且包含了所有附件的原始文件。
• CSV: 这是最通用的格式，几乎能被所有其他密码管理器导入，但不支持附件和自定义字段。

问题在于「一个巴掌拍不响」，至少截至本文写作时，这种新的 1PUX 格式还没有得到其他密码管理器的良好支持。就本文讨论的两个开源选项而言——

Bitwarden

可以比较完整地导入 1Password 密码库中的各个字段，包括银行卡、联系资料和多因素认证信息，但无法导入任何附件。尽管 Bitwarden 本身是支持附件的，但原来的附件导入后只会在 Secure Notes 分类中留下一个落单的文件名，必须重新手动导入。

KeePass

大多数 KeePass 客户端都不支持迁移 1PUX 格式。最流行的 KeePass XC 只在尚未正式发布的 2.8.0 测试版（下载）中增加了支持，并且在我测试中出现了迁移数据库无法保存、多因素认证密钥格式错误等问题。

唯一效果不错的是 Strongbox，不仅迁移过程顺畅，而且格式非常完整、整洁，笔记、附件等内容也得到了完整保留，只能说贵确实有贵的道理。因此，如果你有从 1Password 迁移的需求，即使不准备长期使用 Strongbox 做客户端，也强烈推荐利用它的免费试用期完成迁移。

（但从 1Password 迁移到 KeePass 最大的问题还不是导入效果不佳，而是 KeePass 的默认字段实在过于简陋，难以承接 1Password 中的很多常见字段。这个问题详见稍后的讨论。）

最后简单提一下 Bitwarden 和 KeePass 本身的导出功能：两者都支持通用的 CSV 格式，但同样受限于这种格式的简陋结构，只能记录一部分基础的字段。对于需要保留更完整的信息的情况，Bitwarden 还支持导出为 JSON 格式（文档），多数 KeePass 客户端还支持导出为 XML 格式（文档），但相对而言就没那么通用，并且仍然无法保留附件。

密码填充体验

密码填充是对日常使用体验影响最大的功能，也是最能反映出开发实力高下的功能。同时，作为密码离开安全存储环境的「关口」，如何维持便捷和安全之间的平衡，是密码管理器必须面对的课题。早年，1Password 之所以能获得很多用户的自发推荐，一个很大的加分项就是它对密码填充体验的持续重视。

下面，我们来看看两个开源选项在这个维度上的竞争力如何；这需要分场景分别讨论。

无自动填充框架的系统环境

对于传统的桌面环境，例如 Windows、Linux 和早期版本的 macOS 而言，由于不存在系统级的自动填充框架，在应用程序中填充密码的主要方式就是复制粘贴。因此，使用效率取决于能否快速唤出密码管理器、并找到和复制出所需条目。

这方面，1Password 的一个独家设计是 Quick Access 浮窗：在任意界面按下 Shift-Command/Ctrl-Space，就能唤出一个类似 Spotlight 的浮窗，从中可以手不离键盘完成搜索和复制操作。此外，得益于 1Password 的名气和用户群，macOS 生态的很多第三方软件（例如 Alfred 和 LaunchBar）都内置了 1Password 支持。

相比之下，Bitwarden 和 KeePass 都没有类似 Quick Access 那样的便捷功能。不过，它们确实都有一套完善的快捷键（Bitwarden, KeePassXC），熟悉之后可以只靠键盘来完成唤搜索和复制用户名、密码和验证码的全套操作：

此外，KeePass 还有一套独有的「自动击键」（Auto-Type）功能，用白话描述就是「帮你敲键盘」。

自动击键的用法是：在需要填充的应用程序界面点击输入框，然后切换到 KeePass 找到所需账户并从右键菜单选择 Auto-Type（或者按 Shift-Ctrl/Command-V）。

这时，KeePass 就会 (1) 模拟按下 Alt/Command-Tab 切换到之前的应用窗口，(2) 模拟按键输入用户名，(3) 模拟按下 Tab 切换到密码栏，(4) 模拟按键输入密码，最后 (5) 模拟按下回车完成登录。上述按键序列是可以自己定制的，从而适应各种登录界面的结构。

这种简单粗暴的原理让人不禁想起年代久远的按键精灵，但确实也算有效而且兼容性强。

需要指出，无论基于复制粘贴还是自动击键的填充方式都存在一定的安全风险。理论上，恶意软件可以通过监听剪贴板或键盘操作的方式窃取密码。因此，「自动清除剪贴板」已经成为密码管理器标配的功能（尽管默认启用状态和清空间隔各不相同）；KeePass 还支持所谓的「混淆」功能，在自动输入过程中加入一些无用击键。但这些功能充其量是「防君子不防小人」的，如果系统已经被攻陷到可以后台监听的程度，这种级别的防护也没有太大意义。

有自动填充框架的系统环境

在 Android、iOS 和较新的 macOS 中，系统已经提供了原生的自动填充框架。在这种环境下，登录界面会自动弹出填充密码的提示，并且从密码库中读取登录信息的过程受系统监控和保护。与基于复制粘贴的方式相比，这种机制更方便也更安全，但前提是密码管理器要主动适配相应的原生框架。

这方面，做得最好的仍然是 1Password，基本上总能在第一时间支持各个平台的这类功能。但随着时间推移，Bitwarden 和不少 KeePass 兼容客户端也已经迎头赶上：

可以看到，Bitwarden 的一个明显缺失是至今不支持 macOS 上的系统级自动填充；KeePass 阵营则完全取决于应用，而其中支持 macOS/iOS 系统自动填充的 Strongbox 和 KeePassium 都将其作为收费功能。这也再次说明「省钱」确实不足以成为放弃 1Password 的充分理由。

浏览器环境

浏览器环境对大多数用户而言都是填充密码最频繁的场景。虽然复制粘贴仍然也能凑合，但要实现比较好的体验，还是需要浏览器扩展的支持。⁶

如果你观察比较仔细，应该注意到密码管理器的浏览器扩展有两种实现方式：

1. 浏览器扩展是主程序的延伸，通过加密的 IPC（进程间通信）与主程序交换登录信息。这种方式的好处是体验更无缝，因为密码库的内容、解锁状态可以在主程序和浏览器之间同步，但缺点则在于依赖于主程序在后台持续运行。
2. 浏览器扩展独立运行，相当于一个全功能客户端。这种方式的好处是无需额外安装主程序，比较适合在非主力的浏览器或设备上使用；缺点则是一般占用资源更多，而且从安全角度而言，多运行一个客户端相当于扩大了攻击面。

本文考察的产品中：

• 1Password 的浏览器扩展同时支持这两种模式，取决于是否开启设置中的「浏览器整合」功能。
• Bitwarden 的浏览器扩展只支持独立运行。
• KeePass 原版完全没有浏览器扩展，需要安装插件后和兼容扩展一起使用。KeePassXC、Strongbox 等比较完善的兼容客户端则有自己专属的浏览器扩展，都依赖与主程序的通讯。（曾经还有过一些可以作为浏览器插件独立运行的客户端，但都不维护了。）

至于使用体验，设计最精致的还是 1Password，但功能方面各家差异不大，都支持在登录界面自动填充以及在注册界面自动保存，也都支持在页面上叠加填充选项和右键快捷菜单。

不过，Bitwarden 倒是有一个突出之处：它的账户关联域名设置是最灵活的；除了支持按照完整网址或次级域名匹配，还支持按照网址的开头部分甚至正则表达式匹配。这特别适合那些登录网址和主站域名不一样的服务（例如微软、苹果等大厂共用一个账号的不同子服务、Stack Overflow 站群等），可以省去很多一一添加关联域名的麻烦。

最后需要提示的是，自动填充是密码管理器安全隐患的「重灾区」。通过伪装成其他服务的登录页面（例如通过 iframe 注入或 WebView 漏洞），恶意网站和应用可以欺骗密码管理器填入它们本来无权访问的登录信息。防御方法倒也简单：关闭「有匹配时自动填充」功能，始终通过点击确认来触发填充，就能避免这种漏洞。

可存储数据类型

随着密码管理器的发展，用户已经不再满足于只用它来存储登录信息，还会希望把它当作一个「数字保险箱」，记录一系列值得「保密」或者需要反复使用的信息和文件。同时，随着安全要求提高，登录凭据已经不再限于最传统的账户密码，一次性验证码（TOTP）、通行密钥（passkey）等技术陆续登场。这些变化都对密码管理器存储数据类型的灵活性提出了更高的要求。

非标准记录类型

在支持的记录类型上，1Password 显然走在了前面，打开它的新建窗口可以看到令人眼花缭乱的二十几种选项，包括安全笔记、信用卡和银行账户、联系信息、身份证件（驾照和护照），甚至软件许可、无线网络等等。

虽然从本质上来说，这些额外类型只是数据库条目的不同「模板」，技术含量不高，但确实对日常用户比较友好，也起到了鼓励用户更频繁使用的效果。

相比之下，Bitwarden 提供的记录类型就要朴素不少，除了账户密码只有安全笔记、信用卡、联系信息这三种，不过也算基本够用。

最简陋的要数 KeePass。它的数据库根本就不存在「记录类型」这回事，默认的新建记录至今还是基于用户名、密码和网址这传统「三件套」设计。如果需要记录额外信息，只能通过增加自定义字段来曲线救国。

如果硬要在 KeePass 系软件中实现类似于 1Password 那样的非标准记录类型，就要使用「模板」功能：手动创建一些设置好自定义字段、并将实际信息留空的记录，然后将其放在一个专门的分组中。这样，以后新建条目时就可以直接从中选择。部分兼容客户端（例如 Keepass2android）还会预置一些模板，帮用户一键写入密码库；Strongbox 则还支持在导入 1Password 数据时自动创建对应原有记录类型的分组。

但是，关于应当预置哪些模板，这些模板分别应该包含哪些保留字段，以及用什么名称来识别这些保留字段，各兼容客户端之间并未形成共识（尽管有一些友好但没啥成果的讨论）。此外，即使通过模板创建了收件地址、信用卡等经常需要自动填充的信息，也无法在浏览器中自动填充。这都极大限制了模板功能的实际价值。

不过，「得益于」国内的网购平台几乎已经完全炸毁了 web 端，也很少需要直接使用信用卡支付，所以收件地址和卡片信息填充对于国内用户几乎没有用武之地，不支持的影响也比较有限。（也不知道该说「因祸得福」还是什么……）

一次性验证码（TOTP）

这是一种比较传统的多因素认证机制。根据目前的主流做法，在启用一次性验证码时，服务端会展示一个二维码，用户通过密码管理器扫描保存，以后就可以生成一次性验证码。而这个二维码的内容其实是一个形如 otpauth://totp/LABEL?PARAMETERS 的设置链接，其中记录了生成密钥，账户识别信息（服务名和用户名等），以及配置信息（加密算法、密码位数和刷新周期等）。

因此，要支持一次性验证码，密码管理器需要支持 (1) 识读设置一次性验证码的二维码（或者直接识读设置链接）；以及 (2) 运算和显示一次性验证码。这两者本身都不难，但功力见于细节：除了扫码，能不能直接从屏幕上或相册里抓取二维码？现实中各个服务提供的设置链接格式五花八门，能不能保持最大的兼容性？

比较下来，1Password 和 Bitwarden 的兼容性和便利性都很好，但 Bitwarden 还小胜一筹：它做了个专门界面，可以查阅所有的一次性密码，非常方便。

KeePass 兼容客户端之间则差别比较大，领先的如 Strongbox，和 1Password 不分伯仲；落后的如 KeePassXC，甚至要用户手动粘贴设置链接。（原版 KeePass 甚至连一次性验证码都不支持，好在这在兼容客户端中基本已成为标配功能，并且彼此兼容。）

不过，对于 Steam 玩家而言，1Password 的一个「重大缺陷」在于不支持 Steam 私有的格式（因为开发团队不想支持），反倒是 Bitwarden 和大多数 KeePass 兼容客户端都自主实现了兼容——当然，前提是你愿意花一番工夫把密钥提取出来。

通行密钥（passkey）

这是一种刚开始流行的登录技术，有时也被宣传为「无密码登录」。通行密钥的完整运行机制比较复杂，但其本质还是非对称加密：启用通行密钥的过程会生成一对公私钥，其中公钥保存在服务端，私钥则由用户自行保密。以后，用户端基于私钥完成一定的加密运算，通过服务器的验证即可登录。完成这个验证过程的工具称为「验证器」（authenticator），可以由当前设备上的组件（可能是浏览器、操作系统或第三方密码管理器）充当，也可以由位置临近的外部设备（例如手机或硬件密钥）充当。

因此，当我们讨论「是否支持通行密钥」时，实际上包含好几个不同层次的问题：(1) 是否支持存储和云端同步通行密钥（具体是指其中的私钥）；(2) 是否支持检测支持通行密钥的登录环境，并自动为用户保存和填充密钥；以及 (3) 是否支持调用外部软硬件完成验证。

又因为通行密钥支持涉及浏览器、操作系统和外部验证器等多个组件，实际支持情况形成了一个复杂的矩阵，相当混乱。

但针对我们讨论的场景，也就是将密码管理器用作通行密钥验证器而言，对目前情况的简单概述是：

• 1Password 支持在所有主流浏览器中登录网页服务，在 iOS 17+ 或 Android 14+ 上支持登录移动应用。实际上，由于它的浏览器扩展会主动拦截通行密钥相关的 Webauthn 请求，即使在 Firefox 等尚未正式支持通行密钥的浏览器上，也能实现通行密钥的保存和填充。
• Bitwarden 支持在 Safari 和 Chrome 中登录网页服务，尚未支持登录移动应用。
• KeePass 兼容客户端中，Strongbox 支持在 Safari 和 Chrome 中登录网页服务，KeePassXC 正在测试支持通行密钥，目前只能存储、不能填充；所有客户端均尚未支持用通行密钥登录移动应用。此外，KeePass 并无原生用于存储通行密钥的字段，Strongbox 和 KeePassXC 基于社区共识，增加了几个自定义字段来记录所需信息，日后与其他 KeePass 应用的互操作性还有待观察。

可见，1Password 在适配新技术方面的优势还比较明显。不过，考虑到通行密钥目前还不是一个特别普及的技术，并且 Bitwarden 和众多 KeePass 客户端的开发者都已经宣布致力于完善相关支持，倒也无需过于在意。

最后值得指出，关于是否应当用同一个软件管理普通密码和一次性验证码（或通行密钥），存在不同观点。反对者认为，这么做违反了「多因素」验证的初衷，实际上是将两个「因素」——你的「知识」和「所有物」——混同在一起，其安全性并不比只用密码这一个因素更高。支持者则认为，对于普通用户而言，只要用了密码管理器，就已经比使用弱密码和不开启多因素验证更安全。因此说到底，答案还是取决风险承受能力和担心的攻击级别。如果你确实非常介意，可以考虑用硬件密钥来作为密码库的验证机制，从而补上一个缺失的「因素」。

增值功能

最后，还有一些与密码管理的核心体验无关，但能起到「锦上添花」作用的功能。限于篇幅，这里只简单列表比较，但均附上相关链接，感兴趣的读者可以点击进一步了解。

结语

至此，我们已经充分比较了 Bitwarden 和 KeePass 这两种开源密码管理方案与 1Password 的差异。总的来说，虽然两者都还不能在所有方面和 1Password 这样的商业产品比肩，但在配置得当的前提下，都足以充当主力密码管理器使用。相对而言，KeePass 的初始配置门槛更低，Bitwarden 则在功能上更为完善。

不难注意到，尽管两种开源方案在名义上是「免费」的，但要真正实现可依赖的效果，很多成本还是不可避免。例如，如果自建 Bitwarden，就要花费很多额外时间去部署、维护和备份；如果使用 KeePass，好用的客户端一般都是收费的。我们也指出了这些方案因为「信任」的分散导致的额外风险。因此，不要轻易将「开源」和「安全」画上等号，也不要仅仅出于想省钱或者想折腾的目的就更换工具。开源和闭源并没有必然的高下，免费和收费也都只是综合成本的一个考量因素。比起推荐和不推荐的结论，发现和分析不同方案所隐含的成本和风险，才是本文通过这些对比分析更想传达的思路。

此外，密码管理器终归只是实现密码安全的一个辅助工具。如 Bruce Schneier 所言，在安全链条中，最弱的一环往往就是人自己。比起纠结功能和成本之间的细微差别，了解安全原理、提高安全意识可能是更值得投入时间的事情。

最后祝你身……密码健康，再见。