Passkeys 是一个陷阱，请勿使用

# 通行密钥是个陷阱，不要使用 来源：https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-not-use-them 似乎每个网站都在劝我们别再用密码了。取而代之的是一种叫 *通行密钥（passkeys）* 的东西。如果你已经习惯了密码，又对这些概念模糊的通行密钥一知半解，那这应该让你有些警惕。 网站宣称通行密钥 *更安全*、*更方便*，或诸如此类的好处。虽然通行密钥确实可能远比密码安全，也确实可能更方便，但故事并非全貌。通行密钥的设计初衷并不是以你的利益为优先。就像特洛伊木马一样，通行密钥表面看来确实精巧优雅，但内部藏着令人不安的东西。 最重要的是要知道：与其他任何类型的登录凭据不同，**你并不拥有对通行密钥的最终控制权**。用密码时，你可以选择把它写在哪里；用验证器应用时，你可以自行决定用哪个（它们基本可以互换）；用实体安全密钥时，如果你足够信任同事，也可以把密钥交给他。但通行密钥背后藏着一个隐藏的旋钮，让使用它的网站能够逐渐剥夺你随意处置通行密钥的能力。 我会在下文解释这如何实现，但先来看看是谁希望你使用通行密钥。 通行密钥是 FIDO 联盟（https://en.wikipedia.org/wiki/FIDO_Alliance）的发明 [1](https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-not-use-them#footnote-1)，这是一个由多方不同利益体组成的联盟——科技巨头、小型科技公司、各国政府、情报机构、银行、各类公共机构，甚至还有 Mozilla 这样的少数非营利组织——它们在通行密钥是一件正当且有益的事情上达成了一致。 FIDO 联盟的成员各有各的利益。科技巨头希望给我们的生活制造小麻烦，以便向我们投放更多广告。情报机构想追踪全世界的人。银行想摆脱赔偿责任。小型科技公司想要低成本方案来减少责任。Mozilla 则不希望在任何一条战线上站队而牺牲自己 [2](https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-not-use-them#footnote-2)。我并非说这些动机本身有什么不好。但值得注意的是，没有任何消费者权益倡导组织是 FIDO 联盟的成员。（这与万维网联盟（https://en.wikipedia.org/wiki/World_Wide_Wide_Consortium）形成鲜明对比——后者是制定 Web 标准的组织。除了常见的企业成员外，它还吸纳了公共利益团体、大学，以及 1989 年发明万维网的英国计算机科学家 Tim Berners-Lee。说真的，如果甘道夫本人加入 W3C，也毫不违和。）对于 FIDO 联盟来说，没有任何人在场为用户自身的利益据理力争。 向公众提出的"现在人人都需要使用通行密钥"的理由是：密码不安全。这一点我同意。想想看，价值十亿美元的美国 IT 公司 SolarWinds 的服务器曾被发现 [使用了](https://www.cnn.com/2021/02/26/politics/solarwinds123-password-intern/) `solarwinds123` 作为密码。夏威夷紧急事务管理局（就是发出那次虚假导弹警报的同一个机构）曾因某人桌上的一张便利贴出现在照片背景中而 [意外泄露了密码](https://www.businessinsider.com/hawaii-emergency-agency-password-discovered-in-photo-sparks-security-criticism-2018-1?op=1)。如果你的安全建立在一个密码之上，你将永远提心吊胆，怀疑某个人、在某个地方，不知怎么已经猜到了你的密码，并且已经能访问你的银行账户了。 另一方面：密码的优点在于它非常直观，人人都知道怎么用，人类从远古时代就开始使用密码，而且你可以选择把它存储在哪里、与谁共享。请记住这一点。 （也请记住：Netflix 不想让你分享密码。） 但 FIDO 联盟声称通行密钥解决的安全问题，其实早就被解决了：最初是通过*双因素认证*（特别是：通过短信或邮件接收一次性验证码），后来则有了更完善的*基于时间的一次性密码*（TOTP）系统——通俗地说，就是"验证器应用"。 TOTP 的妙处在于它完全不依赖短信、邮件，甚至不需要互联网。你的验证器软件只需根据当前时间（加上一个专属于你的随机起始值，称为"种子"或"密钥"）每隔 30 秒生成一个看起来随机的数字，网站只需要这个就能验证你的身份。"验证器应用"这个术语有误导性，部分原因在于网站往往会强烈暗示你需要下载某一款 *特定* 应用，比如 Google Authenticator。实际上，TOTP 有一个开放标准（称为 [RFC 6238](https://en.wikipedia.org/wiki/Time-based_one-time_password)）；换句话说，生成这些看起来随机的数字所用的公式是公开的，所以你不必使用任何特定软件。在绝大多数情况下，你不必仅仅因为网站建议就去使用 Google Authenticator。你甚至不需要智能手机；你可以用笔记本电脑，甚至用 90 年代的 Game Boy [3](https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-not-use-them#footnote-3)来完成这件事。只要设备能大致报时、能处理几行代码，你可以使用任何你喜欢的软件和硬件。你甚至可以用 Python 自己编写软件，或者，如果你想浪费那么一丁点"航空燃油"，也可以让大语言模型替你写。 TOTP 是一个很好的方案。如果你不小心在桌面照片中泄露了 TOTP 密钥，你只有几分钟的风险窗口，之后验证码就过期了。TOTP 当然不如密码直观，但至少和密码一样，你可以选择存储方式。你可以决定它存放在哪里，选择用什么软件来生成验证码。而且你不容易像用 `password123` 那样因为选了一个容易猜到的 TOTP 码而弄巧成拙——它们不过是看起来随机的数字，所有 TOTP 码的猜测难度是一样的。哦，还有，你可以把一个验证码发给朋友，让他们在你出差期间临时登录你的 Netflix 账号。如果你愿意，你甚至可以共享你的 TOTP 种子本身，这样朋友就能自行生成你的 TOTP 码，然后让他们 *他们的* 朋友也能登录你的 Netflix 账号。如果你像记密码一样把所有 TOTP 种子写在纸上，可能会引来一些奇怪的目光，但归根结底，这些数据是 *你的*，你可以随意处置。开放标准是不是很棒？ （Netflix 也不想让你共享 TOTP 密钥。） 那么，*通行密钥* 到底有什么不同？表面上看，它们和 TOTP 非常相似。两者都有开放标准（TOTP 用 RFC 6238，通行密钥用 WebAuthn），所以通行密钥一定也具备 TOTP 的所有这些良好特性，对吧？乍一看似乎如此。事实上，我刚刚用自由开源软件生成了一个通行密钥，然后通过电子邮件把它发给了一个朋友，现在我们都可以用这个通行密钥访问同一个网站。我全程没有向任何人征求许可——不需要问网站，不需要问 FIDO 联盟，甚至不需要问我朋友，她还好脾气地让我独占了她的时间而毫无怨言。而且，使用通行密钥不需要手打任何数字，不需要记住任何口诀，通行密钥就是能直接用。仅凭这一点来看，通行密钥确实很方便。而且我 *似乎* 可以对我的通行密钥做任何想做的事。 （但 Netflix 不想让你共享通行密钥。） 那么问题出在哪里？ 问题是：还有另一种东西也叫"通行密钥"，它和我刚描述的那种好东西完全不同。 事实上，有许多不同的东西都被叫做"通行密钥"，而 FIDO 联盟有意将它们全部取了同一个名字。我认为这是为了故意迷惑用户，让他们不去仔细看细则。的确，在技术文档中，定义通行密钥的 WebAuthn 标准几乎完全不使用 *passkey* 这个词。取而代之的是 *可发现凭据（discoverable credentials）* 和 *不可发现凭据（undiscoverable credentials）*；有 *硬件支持凭据（hardware-backed credentials）* 和 *软件支持凭据（software-backed credentials）*；有 *经过认证（attested）* 和 *未经认证（unattested）* 的凭据，还有更多更多。 通行密钥可以拥有的可选组件太多了，以至于规范读起来不像是一个标准，更像是一份零件目录。那么，让我们来看看这份目录中除了我前面描述的那种好用的、也许还算直观的通行密钥之外，还有什么。我会尽量以最好的角度来呈现它们，以便你能理解为什么有些人确实推荐通行密钥作为好的安全方案，但我希望在列举完之后，你能看到我所看到的问题。 两种都存在。 当你生成一个通行密钥时，它可以被设置为 *不可复制的*。作为用户，你可能想要这样做的原因是：只要你持有你的通行密钥——比如说你的 iPhone 在你口袋里——就没有其他人能访问你的账户。另一方面，通行密钥也可以被设置为 *可复制的*，你可能想要这个功能以便在你的多台设备之间共享一把密钥。 如果你要创建通行密钥，一定要弄清楚你创建的是这两种中的哪一种！如果你以为自己的通行密钥是其中一种，而实际上是另一种，某天你一定会不好受——要么当你发现无法把唯一的通行密钥从快要报废的笔记本电脑上抢救出来，要么当别人不知怎么持有了一份你的密钥而你此前并不知道这竟然是可能的。 两种都存在。 令人惊讶的是，即使一个通行密钥是 *不可复制的*，它仍然可以是 *可转移的*。这可能与你对数据应该如何运作的直觉相违背。虽然这一直是物理世界中物体运作的方式，但我们在 *数字* 世界中很少遇到这样的情况：把某个东西发给朋友，它就从你自己的设备上消失了。 你可能希望你的通行密钥不可转移，以确保绝对需要物理持有某一台特定设备才能访问账户。另一方面，你可能希望你的不可复制的通行密钥是可转移的，这样当你明年换新手机时，密钥能随你迁移。（又或者，你只是想和朋友们玩一种先锋派的数字接力赛，作为一种艺术宣言。） 两种都存在。 即使你不是技术达人，你可能也知道 *文件* 和 *文件夹* 是什么——至少如果你有一台台式电脑的话。诚然，智能手机在设计上有意模糊了下载的那个文件到底在哪里、*文件夹* 这个概念是否还算靠谱等问题。（是的，智能手机 *确实* 使用文件和文件夹。它们只是通常不像台式机那样自带文件管理器。） 那么，我们目前讨论的这些通行密钥不就是文件嘛？嗯……并不完全是。也就是说，它们 *可以* 是文件。但也可以不是。就像通行密钥可以选择性拥有的其他所有特性一样，通行密钥也可以选择性地完全不是文件。事实上，由于文件是可复制的、可转移的，以及各种符合直觉的特性，如果通行密钥必须是文件，那就不清楚人们如何才能制造出一个不可复制的通行密钥了。 于是 *硬件支持的* 通行密钥应运而生。它们利用了所有现代设备都配备的安全芯片，这种芯片可以存储无法被提取的数据（意思是数据无法离开安全芯片的保护范围）。不同种类的芯片有不同的名称：你的笔记本电脑有一个可信平台模块（TPM），iPhone 有一个"Secure Enclave"，等等。你在设备的文件管理器中找不到这个区域。[4](https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-not-use-them#footnote-4) 它是一个完全独立的组件。由于它们的加密用途（以及也许是因为它们的神秘感），人们开始把这些芯片称为"密码处理器（cryptoprocessors）"。 共识似乎是：密码处理器确实非常安全。你可能会想，有技术的人难道不能用合适的工具把芯片外科手术般地打开，直接提取数据吗？这在 *理论上* 是可能的；然而，这类芯片采用了各种化学和电子防篡改措施，如果你试图这样做，它会自我销毁。[5](https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-not-use-them#footnote-5) 因此，除非你有国家级的资源，否则基本上可以假定——暂且不论厂商可能留有后门——没有人能从你的密码处理器中取出秘密数据；Netflix 不能，你的操作系统不能，甚至你自己也不能。 你可能更喜欢使用软件支持的密钥，因为你理解文件的工作方式，而且你已经有一个适合自己的私有数据存储方案。你可能想使用硬件支持的密钥，以获得近乎坚不可摧的密码处理器带来的额外安全性。 两种都存在。 有些通行密钥需要有人按下按钮或点击提示来确认认证。另一些则完全不需要有人参与。 你可能想要前者，因为你自己是人类。你可能想要后者，因为你希望授权某个软件代你行事。 两种都存在。 好吧，也许确实有 *一个* 用户在场，但我们怎么知道是 *正确的* 用户在场呢？通行密钥可以选择性地要求 *生物识别验证*（例如指纹传感器或视网膜扫描），或者要求输入 PIN 码或密码，以确保只有一个特定的预期人类才能使用它们。 你可能想要用户验证型通行密钥，以便即使在小偷偷走你的设备时也能确保安全。你可能想要无需用户验证的通行密钥，因为你打算把平板借给家人，让他们在 Amazon 上阅读你的电子书、在 Spotify 上听你的音乐、在 Disney+ 上看你的电影。 事情在这里拐了一个弯。 我之前把这些特性都描述为 *由你来决定* 的。在大多数网站上——至少目前——确实如此。毕竟，Twitter 有什么理由告诉我应该在那一大堆可用的安全措施中为我的通行密钥选择哪些呢？但你应该知道，FIDO 联盟在制定标准时要求你的通行密钥软件必须向你正在访问的服务 *告知* 这些功能中的哪些是被启用的。在 WebAuthn 标准中，它们被称为 *验证器数据标志（authenticator data flags）*。[6](https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-not-use-them#footnote-6) 这意味着 Twitter（正式名称为 X）可以对你说："抱歉，我们这里只接受用户在场且经过用户验证的、不可复制的、硬件支持的通行密钥。但是嘿！你仍然可以在可转移和不可转移的通行密钥之间选择！"其实，我这还算乐观的——我猜他们不太可能说得如此直白。他们大概只会说："很遗憾，您的通行密钥安全性不够，请下载我们的应用。" 但这是一个开放标准，不是吗？也许你有一个精通 Python 编程的朋友。你难道不能直接……