通行密钥是一种陷阱
通行密钥——基于公钥密码学的登录凭据，通常由 Apple、Google 或密码管理器同步——因比密码和 TOTP 码更能抵御钓鱼、并显著改善日常登录体验而受到称赞。然而，批评者认为 WebAuthn/FIDO 标准本身支持与特定硬件和操作系统栈绑定的“已证明”通行密钥，网站最终可能会要求这种凭据，从而把用户锁定在大型平台内，并把 FOSS 或未获批准的设备排除在外。许多人认为当下这种方便、可复制的通行密钥可能是一匹特洛伊木马：现在安全且有用，但如果远程证明被广泛强制执行，未来就存在供应商控制和用户自由受限的真实风险。
对通行密钥的感知收益
- 许多人强烈支持通行密钥，认为它们具备抗钓鱼能力：密钥与域绑定、从不传输，且被盗的服务器数据库只会泄露公钥。
- 很多人认为，与密码 + TOTP/SMS 相比，它们的用户体验好得多：“点一下就进”，无需输入验证码、无需密码复杂度规则、无需重复使用密码。
- 支持者指出，它们本质上就是包在浏览器/操作系统 UX 里的“SSH 风格”公钥认证，解决的是用户永远不会手动管理的问题。
- 硬件令牌（FIDO/U2F 密钥、Yubikeys）以及由密码管理器托管的通行密钥，因兼具强安全性和一定的用户控制而受到称赞。
主要担忧：证明、控制，以及“陷阱”叙事
- 核心担忧：WebAuthn/Passkey 规范支持远程证明，允许网站要求基于硬件、不可导出、且经平台批准的凭据。
- 担心一旦通行密钥被广泛采用，主要网站（尤其是银行、流媒体、社交平台）就会“打开开关”并：
- 拒绝未证明或由软件管理的通行密钥（Bitwarden、KeePassXC 等）。
- 将 FOSS 设备、自定义 ROM、已 Root/解锁 Bootloader 的手机以及非标准操作系统挡在外面。
- 不少人认为这属于更大的“可信计算 / 安全启动 / DRM / 设备证明”趋势的一部分，会削弱用户控制。
- 另一些人则认为这种担忧被夸大了：证明是传统企业技术，在消费级规模上很难运作，而且目前一些主要平台并未使用，甚至也不支持它。
安全性比较：TOTP、SMS、密码、硬件密钥
- TOTP：
- 优点：由用户控制、可移植、可在任何客户端上使用、易于备份。
- 缺点：本质上仍可被钓鱼；服务器上的共享密钥可能被外泄；仍然依赖密码。
- SMS 和电子邮件 OTP 被普遍认为很弱：SIM 卡劫持、拦截、社会工程，以及带来虚假的安全感。
- 有人认为“ TOTP 已经足够好”，通行密钥主要只是增加复杂性和策略风险；也有人把这种说法称作“本十年的‘只要用更好的密码就行’”。
可用性、可移植性与锁定担忧
- 许多人抱怨 UX 碎片化：每个网站的流程都不同（先用户名还是先通行密钥、是否额外要求邮箱验证码等），可能令人困惑。
- 人们不喜欢被迫使用平台自带的通行密钥存储（Apple/Google/Windows），也不想无法选择通行密钥存放位置，或难以导出它。
- 担心如果手机丢失，或者在某个大厂账户被锁定或封禁，就会失去访问权限。
- 重度用户希望：
- 每个账户可配置多个彼此独立的认证器。
- 支持离线备份（包括“金属保险箱”副本）。
- 继续支持密码/TOTP 或 FIDO 密钥作为替代方案。
企业 vs 消费者，以及政策角度
- 很多人同意，证明和严格的硬件策略适用于某些企业或关键基础设施场景。
- 争论的焦点在于这些机制是否会渗透到普通消费级 Web 认证中。
- 有些人认为这主要是一个政策问题（监管、银行规则、企业激励），而不是通行密钥特有的缺陷。
- 另一些人则认为，无论当前是否使用，那些让锁定和证明变得容易的标准本身就很危险。