通行密钥不是陷阱

争论范围

• 大多数评论者承认通行密钥在技术上是可靠的公钥认证，但质疑当前生态系统和标准在易用性上是否友好，以及是否能防止滥用。
• 这条讨论主要集中在：证明和锁定风险、可移植性、UX 失败，以及与密码+TOTP 相比的不同威胁模型。

---

证明、锁定和“陷阱”担忧

• WebAuthn 证明让网站知道认证器型号（AAGUID），并且可能限制允许使用哪些认证器。
• 批评者认为这是一个“旋钮”，以后可以被调高：先采用宽松设置，然后逐步要求经过证明、由厂商批准的认证器。
• 引用的具体例子包括：
  • 只允许 Microsoft Authenticator 的企业 Microsoft Entra 配置。
  • 瑞士和奥地利的电子身份系统只白名单少数硬件令牌。
  • 一位 FIDO 参与者威胁称，不符合规范的 KeepassXC 行为可能导致它被依赖方阻止使用。
• 支持者反驳说：主流消费平台目前返回 none，而大型网站不会冒着立刻把用户挡在门外的风险；一些主要厂商公开不鼓励消费网站使用证明。
• 怀疑者回应说，“现在没用”并不能消除这种能力，且在商业或监管压力下，标准可能会演变。

---

可移植性、生态锁定和备份

• Apple、Google、Microsoft、浏览器和密码管理器之间的体验高度不一致。
• 有些人报告迁移很顺畅（例如 Apple ↔ 1Password/Bitwarden，CXF/CXP 规范），而另一些人则发现：
  • 没有通用导出，只有应用到应用的转移，而且仅限于一个封闭白名单里的应用。
  • 硬件/软件会被明确拒绝（例如 Bitwarden、KeePassXC、Linux+Firefox）。
• 许多人担心依赖单一云账户（iCloud/Google）以及厂商锁定场景；他们重视能够打印或自行归档密码/TOTP 密钥。

---

相较密码/TOTP 的安全优势

• 支持通行密钥的论点：
  • 强大的防钓鱼能力：密钥与域名绑定，不能像密码或 TOTP 代码那样被重放或泄露。
  • 服务器泄露时只暴露公钥；不会发生密码破解。
  • 对于会重复使用密码并受钓鱼影响的非技术用户来说，这是现实中的重大收益。
• 怀疑观点：
  • 具有独特密码和 TOTP 的优秀密码管理器已经缓解了大部分风险；对这类用户而言，额外收益有限。
  • 针对通行密钥生态的攻击确实存在（重置密码/注册钓鱼、有缺陷的实现、设备被攻破、“传递密钥”式问题）。
  • 恢复流程和次要因素（电子邮件/SMS、备用代码）仍然可被钓鱼，因此钓鱼并没有被消除，只是被转移了。

---

可用性、恢复和威胁模型

• 许多人认为通行密钥是一个“令人困惑的烂摊子”：
  • 每个设备上有多个竞争的“管理器”；凭据到底存在哪并不清楚。
  • 在 Linux、虚拟机、远程桌面或没有蓝牙的机器上支持损坏或不完整。
  • 网站对多个通行密钥处理不当，把通行密钥与现有密码+2FA 以奇怪方式混用，或者用暗黑模式强制注册。
• 丢失和恢复：
  • 人们担心丢失所有设备、厂商账户被锁、或跨平台迁移（iOS→Android、企业账户与个人账户之间）。
  • 仅限硬件或带证明的流程会让人担心不可逆的锁定，而今天人们还能保留纸质备份并使用便于迁移的密码存储。
• 威胁模型不同：
  • 有些人优先防范钓鱼和通用攻击 → 倾向通行密钥。
  • 另一些人优先考虑控制、匿名性、抵御厂商滥用或国家胁迫的韧性 → 倾向密码+TOTP 和自主管理的密钥。

---

企业与消费场景的分裂

• 在企业环境中，许多人报告 Yubikey/通行密钥部署很成功，具有强大的集中恢复能力，用户也很愿意摆脱密码。
• 主要担忧在于，这些企业式控制（证明、白名单、强制专有应用）会被应用到消费银行、政府和“必须使用”的服务中。

---

总体情绪

• 支持者：通行密钥是明显升级，尤其是在配合良好的跨平台密码管理器时；对证明机制的担忧被夸大了。
• 怀疑者：通行密钥给平台和依赖方嵌入了新的权力，UX 脆弱、可移植性受限，而“未来旋钮被拧动”的风险使其可能成为长期陷阱。