如今网站都想让我们停用密码，改用一种叫通行密钥（passkeys）的替代方案。网站称通行密钥更安全或更方便，确实可能如此，但这并非全部：其设计并不以你的利益为先。与其他登录凭证不同，你对自己通行密钥没有最终控制权；密码、身份验证器应用和物理安全密钥都能自行处置，而通行密钥却带有一个隐藏开关，让网站能逐渐收回你的控制权。

似乎每个网站都想让我们别再用密码。他们要求我们改用一种叫 passkey 的东西。如果你熟悉密码，却并不完全理解这些含糊的 passkey，这多少该让你有点担心。

网站说 passkey 更安全、更方便，或具有类似的好处。passkey 确实可能远比密码安全，也确实可能更方便，但这并非全部。passkey 的设计并不把你的利益放在首位。就像特洛伊木马，passkey 表面上看确实优雅，里面却藏着令人不安的东西。

关键在于，和其他任何登录凭证不同，你并不对自己的 passkey 拥有最终控制权。用密码，你可以选择把它记在哪里；用身份验证器应用，你可以自己决定用哪一个（它们基本可以互换）；用实体安全密钥，如果你真的信任同事，甚至可以把密钥交给他。但 passkey 附带一个隐藏的旋钮，让你使用它的网站能逐渐夺走你随意处置它的能力。

我会在下面解释这怎么可能，但先看看是谁想让你用 passkey。

passkey 是 FIDO Alliance 的发明。这个联盟由许多相互竞争的利益方组成——大型科技公司、小型科技公司、各国政府、情报机构、银行、各种公共机构，甚至还有 Mozilla 等少数非营利组织——他们难得一致认为 passkey 是件美好而正义的事业。

FIDO Alliance 的成员各有各的算盘。大型科技公司想给我们的生活制造一点小麻烦，好卖更多广告。情报机构想追踪世界上的每一个人。银行想免去赔偿责任。小型科技公司想要便宜的方案来降低自身责任。Mozilla 不想在任何特定问题上死磕到底（虽是玩笑，但 Mozilla 确实有先抗争、最终却让步的名声；比如它最后还是把 Google 专有的 Widevine DRM 塞进了原本开源的 Firefox，因为拒绝可能导致用户看不了 Netflix）。我并不是说这些动机一定恶劣。但有一点很关键：FIDO Alliance 里没有任何消费者权益倡导组织。（相比之下，制定 Web 标准的 World Wide Web Consortium 除了企业成员，还有公益组织、大学，以及 1989 年发明万维网的英国计算机科学家 Tim Berners-Lee。说真的，就算甘道夫本人加入 W3C 也不会违和。）至于 FIDO Alliance，没人在那里强力主张用户自身的利益。

对外宣传的理由是：人人都得用 passkey，因为密码不安全。这点我同意。想想看，美国市值十亿美元的 IT 公司 SolarWinds，曾被曝出 服务器用的密码是 solarwinds123。夏威夷应急管理局（就是误发导弹警报的那家）因为某人办公桌上的便利贴出现在照片背景里，不小心泄露了密码。如果你的安全依赖一个密码，你永远会焦虑：某个地方的某个人，也许已经猜到了它，并且已经能进你的银行账户。

另一方面，密码的优势在于非常直观，人人都懂怎么用，从远古时期就开始用了，而且你可以选择存在哪里、跟谁共享。记住这一点。（另外记住：Netflix 并不想让你共享密码。）

但 FIDO Alliance 声称用 passkey 解决的安全问题，其实早就被解决了：先是有 双因素认证（特别是收到带一次性验证码的短信或邮件），后来又有了更健壮的 基于时间的一次性密码（TOTP）——也就是俗称的“身份验证器应用”。

TOTP 的妙处在于完全不依赖短信、邮件，甚至不依赖互联网。身份验证器软件只是根据当前时间（以及一个只有你有的随机起始数，叫“种子”或“密钥”）每 30 秒生成一个看起来随机的数字，网站靠这个就能确认是你。身份验证器应用 这个说法有误导性，尤其是网站总强烈暗示你必须下载 某个特定 的 App，比如 Google Authenticator。实际上，TOTP 有一个开放标准（RFC 6238），生成这些随机数字的方法是公开的，所以你不必用某一种特定软件。绝大多数情况下，网站建议用 Google Authenticator，你也不必照做。你甚至不需要智能手机，用笔记本电脑、甚至 90 年代的 Game Boy 都行（确实有人做出了 Game Boy 版 TOTP，虽然我不太好意思真推荐你用，但它能让你在派对上受欢迎——至少在我的派对上是这样）。只要设备能大致准确地计时、能跑几行代码，任何软硬件都行。你甚至可以用 Python 自己写，或者烧一点航空燃油让大语言模型帮你写。

TOTP 是个很好的方案。如果你不小心把 TOTP 码泄露在办公桌照片里，风险也只持续几分钟，等验证码过期就没事了。TOTP 当然没密码直观，但至少像密码一样，你还能选择怎么存储。你可以选择让它们存在哪里、用哪个软件生成。你也不会像设个 password123 那样，因为 TOTP 码好猜而搬起石头砸自己的脚；它们只是些看起来随机的数字，全都一样难猜。而且，你出差时可以发一个验证码给朋友，让他临时登你的 Netflix 账号。你甚至可以把 TOTP 种子本身共享出去，让朋友自己生成你的 TOTP 码，然后他们还能让 他们的 朋友登你的 Netflix。如果你像记密码一样把所有 TOTP 种子写在纸上，可能会被人用奇怪的眼神看，但说到底，这些数据 是你自己的，随你处置。开放标准是不是很棒？

（Netflix 同样不想让你共享 TOTP 密钥。）

那么 passkey 究竟有什么不同？表面上看，它和 TOTP 很像。两者都有开放标准（TOTP 是 RFC 6238，passkey 是 WebAuthn），那 passkey 肯定也有 TOTP 那些优点，对吧？乍一看似乎如此。事实上，我刚刚用自由开源软件生成了一个 passkey，然后发邮件给了朋友，现在我俩都能用这个 passkey 登录同一个网站。全程我不需要征求任何人同意，不用问网站，不用问 FIDO Alliance；甚至没问朋友，她 kindly 让我占用了她时间也没反对。而且用 passkey 我不用手输任何数字，不用记任何咒语；它就是能用。单看这一点，passkey 确实方便。而且 看起来 我可以拿我的 passkey 为所欲为。

（但 Netflix 不想让你共享 passkey。）

那么坑在哪里？

坑在于：还有另一种东西也叫“passkey”，它和我刚描述的好 passkey 完全不同。

事实上，有很多不同的东西都叫“passkey”，而 FIDO Alliance 故意把它们全叫成同一个名字。我认为这是为了故意迷惑用户，让大家不去细看小字。确实，在定义 passkey 的 WebAuthn 技术文档里，几乎根本不用 passkey 这个词。取而代之的是 可发现凭证（discoverable credentials）和 不可发现凭证（undiscoverable credentials）；有 硬件支持（hardware-backed）和 软件支持（software-backed）凭证；有 已认证（attested）和 未认证（unattested）凭证，等等。

一个 passkey 能带这么多可选组件，规格读起来不像标准，倒像零件目录。所以，我们就来看看目录里除了我前面描述的那种还不错、也许几乎直观的 passkey 之外，还有些什么。我会尽量把每种都往好了说，让你理解为什么有些人真心推荐 passkey 作为好的安全方案；但看完这份清单，我希望你能看到我看到的问题。

两种 passkey 都存在。

生成 passkey 时，它可以被设成 不可复制（non-copyable）。作为用户，你想要这个的理由是：只要 passkey 在你手里——比如 iPhone 在你口袋里——别人就进不了你的账号。另一方面，passkey 也可以被设成 可复制（copyable），你想要这个能力，是为了在多个设备间共享同一个密钥。

如果你要生成 passkey，务必搞清楚你生成的是这两种里的哪一种！如果你以为它是其中一种，结果其实是另一种，总有一天你会倒霉——要么发现没法把唯一的 passkey 从快挂掉的笔记本上救出来，要么发现别人竟然也有你 passkey 的副本，而你根本不知道这有可能。

两种 passkey 都存在。

surprising 的是，即使 passkey 是 不可复制 的，它仍然可以是 可转移（transferable）的。这可能违背你对数据运作方式的直觉。虽然物理世界一直如此，但在 数字 世界，我们很少遇到“把东西发给朋友后，它从自己设备上消失”的情况。

你可能想要不可转移，以确保必须物理持有某个特定设备才能登录账号。另一方面，你可能想要不可复制但可转移的 passkey，这样换新手智能手机时它能跟着你走。（或者你只是想和朋友玩某种前卫的数字接力赛，当作艺术宣言。）

两种 passkey 都存在。

即使你不怎么懂数码，你可能也知道 文件 和 文件夹 是什么，至少如果你有台式机的话。诚然，智能手机的设计故意把“你下载的文件到底在哪”以及“文件夹还算不算个妥当概念”这些水搅浑。（是的，智能手机 确实 用文件和文件夹，只是通常不像台式机那样带文件浏览器。）

那我们目前说的这些 passkey 都只是文件，对吧？嗯……其实不一定。也就是说，它们 可以 是文件，也可能根本不是文件。就像 passkey 其他那些可选属性一样，passkey 也可以选择完全不作为文件存在。确实，既然文件是可复制、可转移以及具备各种直观特性的，如果 passkey 必须是文件，那谁也没法做出不可复制的 passkey。

于是就有了 硬件支持（hardware-backed）的 passkey。它们利用所有现代设备都带的安全芯片，芯片能存储无法被泄露（exfiltrated，意思是数据无法离开安全芯片的保护）的数据。不同芯片有不同名字：笔记本上有 Trusted Platform Module，iPhone 上有 “Secure Enclave”，等等。你在文件浏览器里哪儿都找不到设备的这块区域；它是一个完全独立的组件。由于它们的加密用途（也许还有神秘感），人们开始把这些芯片叫做“加密处理器”（cryptoprocessors）。

共识似乎是：加密处理器确实非常安全。你可能会想，有本事的人拿合适工具把芯片剖开，不就能把数据提出来吗？这在 理论上 可行；不过这类芯片采用了各种化学和电子防篡改措施，你一动手它就自毁（据说施乐曾做过一种会碎成 tiny shards 的芯片）。所以除非你拥有国家级资源，否则基本可以认定（假设制造商没留后门）没人能把秘密数据从你的加密处理器里弄出来；Netflix 不行，你的操作系统不行，连你本人也不行。

你可能更喜欢软件支持的密钥，因为你懂文件怎么运作，而且已经有存储私密数据的现成方案。你可能想要硬件支持的密钥，因为近乎无法穿透的加密处理器能带来额外安全。

两种 passkey 都存在。

有些 passkey 需要有人按按钮或点提示来确认认证。另一些则完全不需要任何人在场就能使用。

你可能想要前者，因为你自己是人类。你可能想要后者，因为你想授权某个软件替你行事。

两种 passkey 都存在。

好吧，也许 有 用户在场，但怎么知道是 正确的 用户在场？passkey 可以选择要求 生物识别（比如指纹传感器或视网膜扫描），或者要求输入专属的 PIN 或密码，从而更加确定只有某个特定的目标人才能使用它。

你可能想要用户已验证（user-verified）的 passkey，这样即使小偷偷了你的设备也安全。你可能想要未用户验证的 passkey，因为你会把平板借给家人，让他们在 Amazon 看你的电子书、在 Spotify 听你的歌、在 Disney+ 看你的电影。

说到这里，事情来了个急转弯。

到目前为止，我把这些属性都说成 由你自己决定。至少在目前大多数网站上，情况也许确实如此。Twitter（现在叫 X）有什么理由管我在这份自助餐里该选哪些安全措施？但你要知道，FIDO Alliance 制定的标准要求你的 passkey 软件必须告诉被访问的服务：到底启用了这些特性中的 哪些。它们在 WebAuthn 标准里叫 authenticator data flags（认证器数据标志，例如 UP 是 User-Present，UV 是 User-Verified，BE 是 Backup-Eligible 也就是可复制性，AT 是 Attested）。

这意味着 Twitter（正式名称 X）可以对你说：“抱歉，我们这儿只接受 User-Present、User-Verified、不可复制、硬件支持的这类 passkey。不过嘿！你还能在可转移和不可转移的 passkey 之间选！”其实我还算乐观了——我怀疑他们不太可能说得这么清楚。他们大概只会说：“可惜你的 passkey 不够安全；下载我们的 App 吧。”

但这是开放标准，对吧？也许你有个会写 Python 的朋友。难道你不能自己写个 passkey 软件，只做那种基于文件的好 passkey，不带任何额外安全特性，然后照样告诉网站它是 User-Present、User-Verified、不可复制、硬件支持的 passkey？就不能 撒谎 吗？

哦，当然能。你的 passkey 软件可以随意撒谎，谎报任何 passkey 特性——除非我们说的是 已认证（Attested）的 User-Present、User-Verified、不可复制、硬件支持的 passkey。那种就假不了。

Attested passkey 是你需要知道的最后一种、也是最重要的一种 passkey。这类密钥使用所谓的 远程认证（remote attestation），借助你现代设备里那块防篡改加密处理器，以密码学方式 verify 你用的是几家 经过批准 的 passkey 管理器之一，而不是你自己 vibecode 出来、会撒谎的自定义管理器。

正是这个特性，让你不再能对自己的 passkey 说了算。幸运的是，大多数网站目前还不要求 attested passkey。但 FIDO Alliance 的标准不管你愿不愿意，都把认证做成了 passkey 生态的一部分。而且即使网站不要求认证，他们也能检查你的设置是否支持认证。这意味着，一旦 Twitter（X）确信绝大多数用户不受影响，他们就能拨动开关，开始拒绝未认证的 passkey。

关键在于，远程认证需要你的加密处理器、passkey 管理器软件、设备操作系统和设备固件全都通过远程认证检查。毕竟，你手机的操作系统能完全访问每个跑过的 App 里的所有 0 和 1，所以如果 Twitter（X）连你手机的底层操作系统都不信任，那它信任你的 passkey 管理器也没用。只要其中任何一环出问题——比如说，你的手机停止接收安全更新，于是你装了 LineageOS 这类自定义系统，既保持安全又不用买新设备——Twitter（X）就能发现并阻止你登录。

我要说清楚，远程认证也有正当用途。用要求 attested passkey 的网站，你能确保自己不会不小心装了骗子的假 passkey 应用偷数据——网站会拒绝这种 passkey。即使网站不要求，你可能也想要 attested passkey，因为你可以借认证来核实自己的软件没被黑客暗中篡改。（当然，为此用认证可能有点杀鸡用牛刀；就算设备真被黑了，前面说的硬件支持特性也让 passkey 无法被导出设备。不过这个保证没那么让人安心，因为即使密钥牢牢待在设备上，黑客只要控制了你的手机，照样能用它。至少你总可以关机，暂时切断黑客对你的未认证、硬件支持、不可复制、不可转移 passkey 的访问。）

至于不想要认证的理由：你可能想用 Twitter（X）没有特别批准的软件，比如 Linux，或者刷了翻新操作系统的手机。（或者你心术不正，想骗 Netflix，告诉它你和你三个朋友绝对都是同一个人在用同一台设备。）

（但有了认证，Netflix 终于能阻止你共享 passkey 了。）

在设置 passkey 之前，你有充分理由犹豫。如果你只用要求某一种 passkey 的网站，当另一个网站让你设置另一种 passkey 时，你可能根本察觉不到。别忘了，和密码、短信验证码、TOTP 不同，passkey 被设计成在后台运作，你永远看不到细节。它最多给你一个“确认”提示。（这就是方便的那部分。）我的预期是：行业一开始不会对 passkey 加太多限制，然后逐渐加码，不是同时全加，而是在不同站点上错开推行；几年后，人们会忘记自己曾经还能选择给 passkey 启用哪些安全措施（如果他们当初知道 passkey 还分不同类型的话）。

到目前为止，几乎没人听说过远程认证。绝大多数人用四大操作系统（Windows、Android、macOS、iOS），而不是 Linux、LineageOS、postmarketOS 或 GrapheneOS 这类替代系统。绝大多数人在手机停止更新后不会去换操作系统，而是直接买新手机。所以几乎没人会遇到设备通不过远程认证检查的情况。

不过，attested passkey 真有那么糟吗？毕竟我们本来也不该共享 Netflix 账号。

再看看 FIDO Alliance 的成员名单，戴上你的锡纸帽。情报机构为什么在乎我有没有共享 Netflix 账号？微软又为什么在乎？

对情报机构，以及对微软、Google、Apple、Facebook、Amazon 这类公司来说，给你方便和安全很可能不是首要目标。我认为他们有一个完全不可告人的动机：他们可以用 passkey 来阻止你运行未经批准的软件。

远程认证能让他们验证你的设备“没有能力”做什么事，比如发送和接收加密消息，运行竞争对手的 App，或者在不验证身份的情况下使用社交媒体。他们不想让你关掉手机里强制内置的 AI 图像扫描器——那个会扫描你手机看到的一切、检查有没有裸照的玩意儿。（没错，我是认真的。）

但我还挺喜欢自己决定批准什么软件、不批准什么软件。我很看重浏览器的一点，就是能装扩展来改掉网站上烦人的部分。我可以对新闻网站说“不”，不让视频自动播放；我可以决定哪些广告太侵扰、必须拦掉；我能过滤掉不相关的搜索结果、关掉 AI 摘要；我能屏蔽 YouTube 上那个总在煽动愤怒和对立（大公司管这叫“互动率”）的“推荐视频”功能。如果某个网站还是照旧霸占我的时间，我还有个扩展能在用满一段时间后把它锁掉。这些扩展让我能掌控互联网如何影响我，哪怕大型科技公司更乐意替我做这些决定。但 Google 拥有全球最流行的浏览器 Google Chrome，他们可以取消这些有用扩展的支持（就像今年早些时候对 uBlock Origin 做的那样）；而有了远程认证，他们还能阻止我去用任何不跟着照做的其他浏览器。

还记得我提到的 authenticator data flags 吗？过去只有 4 个。FIDO Alliance 安全标准早期版本（“WebAuthn Level 1” 和 “Level 2”）可选的目录项更少。为了简洁，我在这里略掉一些细节；但既然给了四个独立的二元选项，你可以说那就有 16 种 passkey。2022 年 FIDO Alliance 又加了一些（“WebAuthn Level 3”），好让网站知道你的凭证是否可复制，或者凭证的备份是否存在于某处。现在还有两个标志“留作未来使用”。未来我们的 passkey 还会要求我们什么呢？

我不喜欢滑坡论证，所以我不会说：今天这些保护儿童上网的运动，明天就会变成用来方便识别政治异见者的法律。但我要说，被宣传为方便又安全的 passkey 技术若被广泛采用，是有能力让这类法律轻易得到执行的。

所以，如果你关心自己和别人的隐私，如果你认为人们应该自由选择设备上运行什么软件，应该被允许学习写自己的软件并在自己设备上运行，认为朋友应该能在网上私下聊政治而不受政府干涉，那么我请你拒绝这几十种被混乱打包成同一个“passkey”的安全机制。等大型科技公司提出同样方便安全、但定义更清晰、附加条件更少的东西吧。在那之前，如果你想要安全，你的 Game Boy 也能给你提供 TOTP。

补充一句：我其实也为 passkey 说过不少好话。我甚至还没提它最棒的安全特性之一：在大多数使用场景下，passkey 是 domain-bound（绑定域名）的，能抵御所谓的 中间人攻击（Man-In-The-Middle attacks）。passkey 有非常多惊人特性，我其实很想用、很想推荐；非常遗憾的是，FIDO Alliance 偷偷塞进远程认证，又完全不试图让用户看清这些不同类型 passkey 的区别，把一件好事毁了。幸运的是，如果你想要 passkey 能给的那种高安全性，却又不想附带这些枷锁，其实还有一个 更 安全的方案：YubiKey 这类安全密钥。它们基本就是可以随身携带的物理 passkey，能和其他设备一起用。它们同样属于 WebAuthn 标准，但因为完全自包含，它们的远程认证要求不必外溢，进而锁死你整个操作系统。

讨论气氛对立：多数评论为 passkeys 辩护，认为其域名绑定带来的防钓鱼与防中间人能力远胜密码+TOTP，且在自持密码管理器中仍能保持控制与更好体验；批评者则集中指责 passkeys 无法自行备份迁移、被大厂与暗黑模式强制采用，以及标准中 attestation、userVerification 等约束可能在 B2C 场景侵蚀用户自由。分歧主轴是「安全收益是否值得让渡控制权与便利性」，以及文章指控的 attestation 等威胁是否夸大。

认为 passkeys 的防钓鱼与防中间人能力使其成为更优选择

• 密码或密码+TOTP/OTP 会被钓鱼与中间人转发，而 passkeys 的签名与域名绑定、无法被转发到冒牌站点；对绝大多数消费者来说，一次钓鱼失误就足以丢失账户，因此单凭抗钓鱼就值得采用。还有评论指出，批评文章把 FIDO Alliance 动机往坏处想，却完全没提防止中间人攻击正是 passkeys 的关键设计目标，因而所谓“有力论证”并不成立（较多人） > 密码加 OTP 可被钓鱼，而 passkeys 的签名与域名绑定、无法被转发，仅此一点就值得采用（@tgma）

认为在密码管理器中使用 passkeys 依然可控且体验更好

• 许多人反驳“失去最终控制”的说法：只要把 passkeys 存进 Bitwarden、keepassxc、1Password 等可自持的密码管理器，用户仍能掌控；既然原本用 TOTP 也要依赖验证器或管理器，就没理由不继续用同一软件管理 passkeys，而其体验比手动填 TOTP 码顺畅得多。也有用户承认 passkeys 对非技术用户非常困惑，但在自己工作流中比密码+2FA 省事，易用性优先（较多人） > 在灵活的密码管理器里使用 passkey，真的仍然把控制权交给了用户，而且体验比填 TOTP 码轻松太多（@david_shaw）

认为 passkeys 适合组织内部系统，但面向消费者会危及用户自由

• 一位全面在组织内部启用 passkeys 的支持者表示，passkeys 非常适合在组织内强制统一安全标准；但作为通用 B2C 认证技术，若 userVerification: required 这类额外约束被广泛采用，用户自由会被严重削弱。他以 1Password 近期强制 userVerification 为例：桌面端没有 TouchID 时，反而要同时输入主密码和网站登录密码，破坏了“一个密码”的体验（少数人） > passkeys 在组织内很好，但作为通用 B2C 认证技术，若额外约束被广泛采用，用户自由会受到严重伤害（@oefrha）

认为 passkeys 让人失去对凭证的最终控制、难以备份迁移

• 批评者最集中的不满是：passkeys 无法像密码那样自行备份、迁移或锁进“保险柜”，一旦绑定单一设备，设备丢失就可能被锁死；还有人强调想自行控制不同服务的凭证强度，不认为手机指纹解锁能等同于密码管理器里的长密码。若无法使用自持密码管理器，或厂商做成强制，这种失控尤其糟糕（较多人） > 我只想能备份凭证并锁进保险柜，也不认为用拇指解锁手机能等同于密码管理器里的长密码（@bmitch3020）

认为 passkeys 正被大厂和暗黑模式强制推行

• 不论用户是否想要，大厂都会强推 passkeys；批评者提到应用内会在交易流程中把开启 passkey 做成绿色按钮诱导，关闭却要深挖设置并反复确认，还会登出其他设备，属于把用户资金挟持的暗黑模式。还有人指出 Apple、Google、Cloudflare 已在推动扫码验证手机硬件，桌面使用反而更麻烦，PR 攻势也铺天盖地（较多人） > 知道大厂的作风，这东西不管你想不想要都会被硬塞下来（@Havoc）

认为“最终控制权”的担忧被夸大，大厂问题并不新鲜

• 有人反驳文章对“ultimate control”的执念：我们连自身存在、肤色都无法选择，所谓“最终控制”只是空话；至于大厂把用户当羊群的担忧或许有一点价值，但“小心有钱人的贪婪”并不是什么新发现（少数人） > 如果我们连自身来历都无法选择，“最终控制”就只是一句空话（@newCrotchSmell）

有价值的补充

• 可移植性的一个精巧类比：passkeys 应当被当作可替换的牲畜，而不是需要呵护的宠物——每个账号注册多个、分散存进多个密码管理器，这样即使单个凭证不可复制，也能随时再生成一个，不必纠结能不能拷贝（@skybrian）。
• attestation 的技术现实：WebAuthn 的 attestation 只能在注册凭证时要求，登录时无法追溯追加；浏览器会弹权限提示，且 Apple 的 passkey 实现不支持 attestation。因此文章设想的“先普及 attested passkeys，再翻脸拒绝非 attested”极不可能；在消费者网站真的开始强要 attestation 之前，不应因此退回 TOTP，因为 TOTP 会被钓鱼而 passkeys 不会（@agwa）。
• 一个更简单的替代认证设想：有人疑问为何 Web 认证不直接做成极简挑战—响应：网站返回 HTTP 401 并声明支持 EasyAuth 1.0，客户端回一句带用户 ID、时间戳和数字签名的声明。这其实是把 passkeys 背后的签名思想退回更透明、可直接粘贴的凭证形态（@drhagen）。
• userVerification 等约束的默认值风险：passkey 标准里的 userVerification 等约束可由依赖方设定，且默认值会扩散。更反直觉的是，让 AI 随手 vibe code 一个 Go 的 passkey 认证时，模型每次都默认选 required；作者提醒别在没理解的情况下用 vibe coding 写认证（@oefrha）。
• 匿名与多账户的“感觉”误区：有用户承认 passkeys 让人“感觉”网站在索取更多信息、更难维护多账户、更损害匿名，但这其实不成立——用密码时你同样得自己决定如何生成，每个人方式还不一样；passkeys 主要是心理感受更差，而非实际更糟（@Cider9986）。
• 非技术用户的落差：即便是爱好者也承认，passkeys 对非技术用户而言极其令人困惑，并不是“连普通用户也很友好”的技术；这与“防钓鱼对大众有利”的辩护并不矛盾，只是易用性红利目前主要落在技术用户与组织场景（@Grombobulous）。