Passkeys不是陷阱：深度解析WebAuthn认证机制与安全性
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 上热度很高，我也多次收到别人发来的这篇文章，并附带“这是真的吗？”的疑问语气。这篇文章面向的是“网络世界的非技术公民”，其核心建议是停止使用 passkeys，转而回到 TOTP 验证码和密码。
The Argument
论点
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.
这篇文章提出了一个看似核心的主张：Passkeys 支持一种称为“认证”（attestation）的功能，它允许网站请求关于 passkey 生成来源的密码学证明。
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 联盟成员名单以及英国的图像扫描提案，结论就是 passkeys “并非旨在优先考虑你的利益”。<that-escalated-quickly.gif>
It's a compelling story. It just doesn't match how any of this actually works...
这是一个引人入胜的故事。但它并不符合这些功能的实际运作方式……
Your Passkeys Don't Attest
你的 Passkeys 不进行认证
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.
大多数人使用的 passkeys 是同步 passkeys，存储在 iCloud 钥匙串、Google 密码管理器、1Password、Bitwarden 或你选择的任何其他软件中。这些 passkeys 根本不会向网站提供认证声明，虽然网站可以请求，但返回的结果为空。我知道这一点，因为我编写了一个开源的 passkeys 库并将其公开给所有人使用。
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.
如果一个消费类网站决定从明天起只接受经过认证的 passkeys，它将立即锁定几乎所有自己的用户。哪家网站会这么做？此外，多年来针对消费类网站的指导方针一直是甚至不要请求认证。
Attestation Isn't What You Think It Is
认证并非你以为的那样
The post describes attestation as proving "that an approved passkey manager, operating system, and firmware are in use" which is simply not true.
文章将认证描述为证明“正在使用经过批准的 passkey 管理器、操作系统和固件”，这显然是不正确的。
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、固件版本，甚至颜色，都一无所知。
The YubiKey Recommendation
YubiKey 推荐
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 是具备认证（attestation）功能的身份验证器。每一把 YubiKey 都附带由 Yubico 签发的认证证书，而企业级认证功能的存在，正是为了让组织能够要求使用经过批准的硬件密钥。我仍然向任何想要购买的人推荐 YubiKey，它们非常出色，我自己也在用；但如果你的担忧在于认证功能，那么这篇文章本身的建议其实是引导你走向认证，而不是远离它！
TOTP Is a Step Backwards
TOTP 是一种倒退
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...
这正是 passkey 所解决的问题。passkey 与其创建时的域名绑定，因此你的浏览器绝不会在 examp1e.com 上使用你为 example.com 创建的 passkey。无需读出代码，用户也不会出错。作者甚至在附录中承认了这一点，指出 passkey 具有域名绑定特性并能抵御中间人攻击，但仍然劝读者避免使用它们。用抗钓鱼的凭证替换易受钓鱼攻击的凭证，是一个极其糟糕的权衡……
What You Should Do
你应该怎么做
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.
继续使用 passkey！只要网站提供 passkey，就接受它，并将其存储在你信任的密码/passkey 管理器中。如果你希望能够在不同设备或平台间迁移凭证，请选择支持该功能的提供商。如果你担心认证功能会渗透到消费者登录场景中，那么值得大声反对（如果真发生的话）。但这种情况尚未发生，最大的提供商也不支持它；而在等待其出现的同时回避使用 passkey，并不能保护你免受任何威胁，只会让你更容易遭受钓鱼攻击。
Sources
参考资料
I have some experience in this area:
我在这一领域有一些经验：
I created WhyNoPasskeys.com to track the availability of passkeys on the Web.
我创建了 WhyNoPasskeys.com，用于追踪 Web 上 passkey 的可用性。
I built and deployed passkeys support on my own SaaS company.
我在自己的 SaaS 公司构建并部署了 passkey 支持。
We built our own passkeys library and had it security reviewed.
我们构建了自有的 passkey 库，并进行了安全审查。
I wrote about Security considerations when using Passkeys on your website.
我撰写了关于在你的网站上使用 Passkey 时的安全注意事项的文章。
I wrote Passkeys 101: An Introduction to Passkeys and How They Work.
我撰写了《Passkey 101：Passkey 简介及其工作原理》。
I made our passkeys library opensource for everyone to use.
我们将我们的 passkey 库开源，供所有人使用。
I've done extensive security testing of passkeys implementations.
我对各种 passkey 实现进行了广泛的安全测试。
I've openly acknowledged the limitations of not using attestation on passkeys.
我已公开承认在 passkey 中不使用 attestation 的局限性。
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.
我认为最重要的是说明，我尽可能在所有地方使用 passkey，因为它们是目前我们保护账户的最佳手段。而且它们并非陷阱。
Have you enjoyed this post or found it helpful?
你喜欢这篇文章或觉得它有帮助吗？
☕️ Consider buying me a coffee to say thanks!
☕️ 考虑请我喝杯咖啡以表感谢！
🔔 Subscribe for free notifications when I publish!
🔔 在我发布新内容时免费订阅通知！
🤩 Become a member and support my content!
🤩 成为会员并支持我的内容！
Tags: Passkeys
标签：Passkeys
更进一步：量化金融体系
看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力