通行密钥不是陷阱
Passkeys are not a trap

原始链接: https://scotthelme.co.uk/passkeys-are-not-a-trap/

一篇病毒式传播的帖子声称通行密钥是陷阱,并呼吁回归密码和 TOTP。反驳文章称,其核心主张——通行密钥能通过隐藏证明来控制获准的软件、操作系统和固件——是错误的。大多数通行密钥是同步的,不提供证明;消费级网站很少请求它,如果强制要求,会把用户拒之门外。WebAuthn 证明仅通过 AAGUID 识别认证器的品牌/型号,而不是你的操作系统、浏览器、root 状态或扩展程序。该帖子推荐 YubiKey 自相矛盾:YubiKey 本身支持证明。TOTP 可被钓鱼——验证码可被实时转送——而通行密钥绑定域名并能抵御钓鱼。作者建议:只要提供通行密钥就继续使用,将其存储在受信任的管理器中,选择允许可移植性的提供商,并反对未来任何强制消费者证明的推动。通行密钥不是陷阱。

一篇关于“通行密钥不是陷阱”的 Hacker News 讨论,辩论通行密钥是提升安全性,还是造成锁定和困惑。文章认为通行密钥不是监控陷阱,因为当前 WebAuthn 证明不会泄露操作系统/浏览器细节,而大规模证明要求会把用户拒之门外。评论者反驳说,通行密钥设置是一团糟的用户体验:凭据可能落入 Google、三星、iCloud 或 Windows 管理器中,使跨设备使用和整合变得复杂。一些人担心供应商锁定、手机丢失后无法访问,以及未来强制要求硬件/操作系统证明或生物识别——而这些可能像密码一样,甚至在法律上可被强制提供。另一些人则为通行密钥辩护,认为它更安全、更顺畅,尤其是在 Apple 生态系统中,或通过 Bitwarden、1Password 等可同步密码管理器使用时。公司赞助的密码管理器也受到批评,不过有些人会把个人账户分开。总体而言:支持者认为这是正常的成长阵痛;怀疑者认为这是滑向平台控制的滑坡。
相关文章

原文

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.

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.

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>

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

Your Passkeys Don't Attest

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.

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.

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.

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.

The YubiKey Recommendation

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".

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!

TOTP Is a Step Backwards

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.

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...

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.

Sources

I have some experience in this area:

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

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

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.

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.

联系我们 contact @ memedata.com