本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

Passkeys are not a trap

A post called Passkeys are a trap. Do not use them. has been doing the rounds over the last few days, making it pretty high on Hacker News, and I’ve had it sent to me many times with an ‘is this true?’ kind of vibe. It’s written for “non-technical citizens of the web”, and the headline advice is to stop using passkeys and go back to TOTP codes and passwords.

一篇名为《通行密钥（Passkeys）是一个陷阱，不要使用它们》的文章在过去几天里广为流传，在 Hacker News 上热度很高。我多次收到这篇文章，人们总是带着“这是真的吗？”的疑问来问我。该文是为“非技术背景的网络用户”撰写的，其核心建议是停止使用通行密钥，转而使用传统的 TOTP 验证码和密码。

The post makes what appears to be one central claim: Passkeys support something called attestation, which lets a website ask for cryptographic proof of what made the passkey.

这篇文章提出了一个看似核心的观点：通行密钥支持一种名为“认证（attestation）”的机制，它允许网站要求提供加密证明，以确认通行密钥是由什么生成的。

The author calls this a “hidden dial” and argues that sites will slowly turn it up, until you’re only allowed to log in with approved software on an approved operating system, with no modifications, no LineageOS and no sharing your Netflix password. Throw in uBlock Origin, the FIDO Alliance membership list and the UK’s image-scanning proposals, and the conclusion is that passkeys are “not designed to prioritize your interests”. <that-escalated-quickly.gif>

作者将其称为一个“隐藏的旋钮”，并认为网站会逐渐调高这一设置，直到你只能在经过批准的操作系统上使用经过批准的软件才能登录，且不能进行任何修改，不能使用 LineageOS，也不能共享 Netflix 密码。再加上 uBlock Origin、FIDO 联盟成员名单以及英国的图像扫描提案，作者得出的结论是，通行密钥“并非旨在优先考虑你的利益”。<事态迅速升级.gif>

It’s a compelling story. It just doesn’t match how any of this actually works…

这是一个引人入胜的故事，但它与这些技术的实际运作方式完全不符……

The passkeys most people use are synced passkeys, stored in iCloud Keychain, Google Password Manager, 1Password, Bitwarden or whatever other software of your choosing. These passkeys don’t give websites an attestation statement at all, and though a site can ask, what comes back is none. I know this because I wrote an opensource passkeys library and made it available to everyone.

大多数人使用的通行密钥是同步通行密钥，它们存储在 iCloud 钥匙串、Google 密码管理器、1Password、Bitwarden 或你选择的其他任何软件中。这些通行密钥根本不会向网站提供认证声明；即使网站提出请求，返回的结果也是空。我知道这一点，因为我编写了一个开源的通行密钥库并将其提供给了所有人。

If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that? Besides, the guidance for consumer sites has been to not even request attestation for years now.

如果某个消费类网站明天决定只接受经过认证的通行密钥，它会瞬间将几乎所有用户拒之门外。有哪个网站会这样做呢？此外，多年来针对消费类网站的指导方针一直是不建议请求认证。

The post describes attestation as proving “that an approved passkey manager, operating system, and firmware are in use” which is simply not true.

该文章将认证描述为证明“正在使用经过批准的通行密钥管理器、操作系统和固件”，这完全不是事实。

When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.

当认证存在时，WebAuthn 认证只会告诉网站验证器的品牌和型号（通过 AAGUID 识别），并附带供应商提供的证书链作为支持。它不会透露关于你的操作系统、浏览器、扩展程序、手机是否已 Root 或越狱、固件版本，甚至手机颜色的任何信息。

This is the part that surprised me the most. For people who want stronger security, the post recommends a hardware security key like a YubiKey, because it “avoids OS-wide attestation”.

这是最让我惊讶的部分。对于追求更高安全性的用户，该文章推荐使用像 YubiKey 这样的硬件安全密钥，因为它“避免了系统级的认证”。

YubiKeys are the authenticators that do attestation. Every one of them ships with a Yubico-issued attestation certificate, and enterprise attestation exists specifically so organisations can require approved hardware keys. I’d still recommend a YubiKey to anyone who wants one, they’re excellent and I use them, but if attestation is the thing you’re worried about, the post’s own recommendation pushes you towards attestation rather than away from it!

YubiKey 正是会进行认证的验证器。每一款 YubiKey 出厂时都带有 Yubico 颁发的认证证书，企业级认证的存在正是为了让组织能够要求使用经过批准的硬件密钥。我仍然会向任何想要的人推荐 YubiKey，它们非常出色，我自己也在用。但如果你担心的是认证机制，那么该文章的建议反而是在把你推向认证，而不是让你远离它！

The post holds up TOTP as “already” a great solution. TOTP is better than a password alone, absolutely, but it has one big weakness: you can type the code into the wrong website, just ask my good friend Troy Hunt. Phishing kits like Evilginx sit in the middle, relay your password and code to the real site in real time, and walk away with your session. This isn’t theoretical, it’s how a huge number of account takeovers happen today and we have the evidence to prove it.

该文章将 TOTP 奉为“现成”的绝佳解决方案。TOTP 当然比单纯的密码要好，但它有一个重大弱点：你可能会把验证码输入到错误的网站上，问问我的好朋友 Troy Hunt 就知道了。像 Evilginx 这样的钓鱼工具包会拦截在中间，实时将你的密码和验证码转发给真实网站，并窃取你的会话。这并非理论，而是当今大量账户被盗的真实方式，我们有证据证明这一点。

This is the problem that passkeys solve. A passkey is bound to the domain it was created for, so your browser simply won’t use your example.com passkey on examp1e.com. There’s no code to read out and nothing for the user to get wrong. The author even concedes this in the addendum, saying that passkeys are domain-bound and resist man-in-the-middle attacks, but still tells readers to avoid them. Swapping a phishing-resistant credential for a phishable one is a really bad trade…

这正是通行密钥所解决的问题。通行密钥绑定在创建它的域名上，因此你的浏览器绝不会在 examp1e.com 上使用 example.com 的通行密钥。没有验证码需要读取，用户也不会出错。作者甚至在附录中承认了这一点，称通行密钥是域名绑定的，可以抵御中间人攻击，但仍然告诉读者要避免使用它们。用一种抗钓鱼的凭证去换取一种容易被钓鱼的凭证，这真是一笔糟糕的交易……

Keep using passkeys! Wherever a site offers one, take it, and store it in a password/passkey manager you trust. If you want to be able to move your credentials around, pick a provider that supports that. If you’re worried about attestation creeping into consumer logins, then that’s worth pushing back on, loudly (if it ever happens). But it hasn’t happened, the biggest providers don’t support it, and avoiding passkeys today while you wait for it won’t protect you from anything, it just leaves you open to phishing.

请继续使用通行密钥！只要网站提供，就启用它，并将其存储在你信任的密码/通行密钥管理器中。如果你希望能够迁移凭证，请选择支持此功能的提供商。如果你担心认证机制会渗透到消费类登录中，那么如果这种情况真的发生，值得大声反对。但目前这种情况并未发生，最大的提供商也不支持它。现在为了等待这种可能性而避开通行密钥，并不能保护你免受任何威胁，只会让你暴露在钓鱼攻击之下。

I have some experience in this area:

我在这个领域有一些经验：

I created WhyNoPasskeys.com to track the availability of passkeys on the Web.

我创建了 WhyNoPasskeys.com 来追踪通行密钥在网络上的可用性。

I built and deployed passkeys support on my own SaaS company.

我在我自己的 SaaS 公司中构建并部署了通行密钥支持。

We built our own passkeys library and had it security reviewed.

我们构建了自己的通行密钥库，并进行了安全审查。

I wrote about Security considerations when using Passkeys on your website.

我撰写了关于在网站上使用通行密钥时的安全注意事项。

I wrote Passkeys 101: An Introduction to Passkeys and How They Work.

我撰写了《通行密钥 101：通行密钥简介及其工作原理》。

I made our passkeys library opensource for everyone to use.

我将我们的通行密钥库开源，供所有人使用。

I’ve done extensive security testing of passkeys implementations.

我对通行密钥的实现进行了广泛的安全测试。

I’ve openly acknowledged the limitations of not using attestation on passkeys.

我公开承认了在通行密钥上不使用认证机制的局限性。

I think most of all that it’s important to say I use passkeys everywhere I can because they’re currently the best thing we have available to protect our accounts. And they’re not a trap.

我认为最重要的是要说明，我在所有能用的地方都使用通行密钥，因为它们是我们目前保护账户的最佳手段。而且，它们不是陷阱。