从理想国到现实世界

2024年12月，FIDO联盟在东京发布了最新数据：全球已有超过150亿个在线账户支持Passkey登录，这一数字相比2023年翻了一番。Google报告称其8亿账户使用了Passkey，累计完成25亿次登录，登录成功率提升30%。Amazon创建了1.75亿个Passkey。日本的KDDI通过Passkey将客服电话减少了35%，Mercari实现了零钓鱼事件的记录。

这些数字令人振奋。然而，当我们将目光从宏观数据转向用户体验的微观层面，一系列问题开始浮现：用户真的理解Passkey是什么吗？当设备丢失时会发生什么？为什么Passkey反而可能成为攻击者的新目标？同步Passkey和设备绑定Passkey，安全性真的相当吗？

timeline
    title FIDO技术演进历程
    section 2012-2014
        2012.07 : FIDO联盟成立
        2014.01 : 首次部署<br/>Samsung S5 + PayPal
        2014.12 : 发布UAF和U2F规范
    section 2015-2019
        2016 : W3C启动WebAuthn标准化
        2019.03 : WebAuthn成为W3C标准
    section 2020-2024
        2022 : Apple/Google/微软<br/>宣布Passkey支持
        2024 : 150亿账户支持Passkey

认知的鸿沟

用户眼中的Passkey

USENIX Security 2021发表的一项研究深入调查了用户对FIDO2生物识别WebAuthn的认知。研究者发现了一个普遍存在的误解：许多用户认为他们的生物特征数据（指纹、面部）被发送到了服务器。一位参与者坦言：“它被存储在某个加密服务器上，希望如此。”

这种误解并非偶然。当用户将手指放在手机上完成登录时，他们自然的认知模型是"指纹被验证了"，而非"本地设备使用私钥签名了一个挑战"。这种认知差异带来的后果是深远的——用户无法正确评估风险，也无法在异常情况下做出正确判断。

MDPI 2025年发表的文献综述总结了Passkey采纳的三大核心挑战：

  1. 认知偏差：用户对Passkey的安全模型缺乏准确理解
  2. 账户恢复困境：FIDO2原生缺乏默认的恢复序列
  3. 共享与委托问题：如何安全地与他人共享账户访问权限

“记住此设备"的陷阱

BYU的研究团队在NDSS 2024发表的论文揭示了一个更隐蔽的问题。许多服务提供"记住此设备"功能，用户选择后可以获得一个长期有效的cookie。以Facebook为例，这个cookie的有效期约为两年。

问题在于：攻击者只要窃取这个cookie，就能在有密码的情况下完全绑过2FA。研究团队分析了246,345个Chrome扩展，发现31,326个拥有"cookies"权限，其中18,024个同时拥有访问所有网站的权限。这意味着102个用户量超过百万的扩展，一旦被攻击者控制，就可以窃取用户的"记住此设备"cookie。

这不是理论风险。研究团队在实验中成功将Facebook的"记住此设备"cookie复制到另一台设备，仅用密码就绑过了硬件安全密钥的2FA验证。

账户恢复的死结

没有退路的密码替代方案

FIDO联盟在2019年发布了《FIDO依赖方账户恢复最佳实践》，推荐了两阶段策略：

  1. 注册多个认证器：降低账户恢复需求
  2. 重新运行身份验证流程：实际执行账户恢复

但现实是残酷的。arXiv 2025年发表的ICISSP论文指出，设备绑定Passkey无法提供"易于从丢失中恢复"这一优势。当用户丢失了存储Passkey的唯一设备，他们面临的是一条漫长的身份重新验证之路。

Google Password Manager PIN、Apple iCloud安全码、或者第三方密码管理器的主密码——无论哪种方案，都存在单点故障。一旦用户忘记主密码或丢失恢复密钥，所有同步的Passkey可能瞬间变得不可访问。

12种恢复机制的评估

一项针对FIDO2账户恢复策略的研究评估了12种可能的恢复机制，结论并不乐观。大多数恢复机制要么安全性不足，要么用户体验糟糕。当你的银行账户绑定在Passkey上，而你丢失了手机，你真正需要的是什么？是快速恢复访问，还是绝对的安全保证？

这个问题没有标准答案，但它揭示了一个根本矛盾：密码系统的便利性，恰恰来自于其可重置性。 你可以忘记密码，然后通过电子邮件重置它。但Passkey的设计哲学——私钥永远不离开设备——使得这种便利性变得不可能。

同步还是绑定：一个被忽视的安全分野

四种访问级别

ICISSP 2025的论文将Passkey划分为四种访问级别：

graph LR
    A[设备绑定<br/>Device-Bound] --> B[同步<br/>Synced]
    B --> C[共享<br/>Shared]
    C --> D[导出<br/>Exported]
    
    style A fill:#2ecc71,color:#fff
    style B fill:#f39c12,color:#fff
    style C fill:#e74c3c,color:#fff
    style D fill:#c0392b,color:#fff
访问级别 安全性 可用性 典型场景
设备绑定 最高 最低 YubiKey、企业安全密钥
同步 中高 高 Apple iCloud、Google Password Manager
共享 中 中 家庭账户共享
导出 最低 最高 手动备份迁移 
graph TD
    subgraph 设备绑定Passkey
        A1[私钥存储在安全硬件] --> B1[物理隔离]
        B1 --> C1[抗远程攻击]
        C1 --> D1[★ 最高安全性]
    end
    
    subgraph 同步Passkey
        A2[私钥由提供商加密存储] --> B2[跨设备同步]
        B2 --> C2[依赖提供商安全]
        C2 --> D2[★ 便利性提升]
        C2 --> E2[⚠ 单点故障风险]
    end
    
    subgraph 密码
        A3[用户记忆或存储] --> B3[可重置]
        B3 --> C3[钓鱼风险]
        C3 --> D3[★ 最低安全性]
    end
    
    style D1 fill:#2ecc71,color:#fff
    style D2 fill:#f39c12,color:#fff
    style E2 fill:#e74c3c,color:#fff
    style D3 fill:#95a5a6,color:#fff

安全性的集中化

论文使用Bonneau等人提出的认证评估框架，对密码、设备绑定Passkey、同步Passkey进行了系统比较。结论令人警醒：同步Passkey的安全性高度集中在Passkey提供商。

当你的Passkey存储在Apple iCloud或Google Password Manager中时，你实际上是在信任这些提供商：

  • 他们的账户保护机制足够强大
  • 他们的加密实现没有后门
  • 他们的员工不会被社会工程攻击
  • 他们不会在政府压力下交出你的密钥

2022年的LastPass泄露事件提供了惨痛的教训。攻击者获取了加密的用户数据备份，虽然主密码保护的库尚未被确认破解，但这一事件足以让安全社区重新审视密码管理器的安全模型。当Passkey也以类似方式存储时，同样的风险是否存在？

平台锁定的隐忧

一篇发表在TuxCare博客上的文章直言：“Linux生态系统提供了一个独特的机会，可以在不被任何供应商生态系统锁定的情况下实现Passkey。”

这反映了安全社区的深层忧虑。当你的数字身份绑定在Apple、Google或Microsoft的生态系统中时，你失去了什么？

  • 迁移困难：虽然有FIDO联盟的凭证交换协议草案，但实际跨平台迁移仍然复杂
  • 生态系统依赖：要使用同步Passkey，你必须接受平台的完整服务条款
  • 隐私权衡：平台现在知道了你登录了哪些服务

一位安全研究员在博客中写道：“Passkey的问题大多围绕平台提供商，权力平衡被转移了，对你不利。”

本地攻击：被低估的威胁面

浏览器扩展的隐患

NDSS 2024的论文系统性地分析了针对FIDO2的本地攻击，发现了四个根本性缺陷：

  1. FIDO2消息缺乏机密性和完整性保护：浏览器扩展可以访问明文的FIDO2通信
  2. 克隆检测算法存在漏洞：可以被绕过
  3. 通知和错误消息容易导致用户误解：用户无法识别攻击
  4. Cookie生命周期管理不当：提供了绕过2FA的途径

研究团队构建了恶意浏览器扩展原型，在十个流行网站上成功演示了七种攻击。其中包括两种攻击，在密码世界中根本不存在——攻击者可以登录受害者从未在该浏览器访问过的账户。

七种攻击详解

攻击一：错误绑定攻击

在用户注册硬件安全密钥时，恶意扩展将用户的公钥替换为攻击者的公钥。结果是：服务器注册了攻击者的密钥，而非用户的。当用户尝试登录时，会收到错误消息，但他们很可能将其归因于"密钥坏了"或"我操作不当”。

攻击二：双重绑定攻击

攻击者在用户注册密钥的同时，悄悄注册第二个恶意密钥。用户可以正常登录，毫不知情自己的账户已经"后门洞开"。

攻击三：同步登录攻击

这是最隐蔽的攻击之一。当用户在example.com登录时，攻击者在后台发起对facebook.com的认证请求。用户看到两次"请按安全密钥"的提示，理所当然地认为"第一次没按好"，于是按了第二次。结果？攻击者获得了用户Facebook账户的访问权限。

攻击四：中间人攻击

攻击者拦截用户的认证请求，将其替换为自己设备上的请求，获取用户签名后在自己的设备上创建会话。

攻击五：签名算法降级

虽然目前流行的网站都使用安全的签名算法，但攻击者可以尝试强制使用不安全的算法，为未来的攻击铺路。

攻击六：Cookie生命周期攻击

窃取"记住此设备"cookie，绑过2FA。

攻击七：绕过克隆检测

通过预先增加计数器值，攻击者可以在一定窗口期内使用克隆设备而不被检测。

flowchart TD
    subgraph 攻击者操作
        A[获得设备物理访问] --> B[克隆设备]
        B --> C[发送y个虚拟认证请求]
        C --> D[原设备计数器: x+y]
    end
    
    subgraph 状态对比
        E[克隆设备计数器: x]
        F[服务器计数器: x]
    end
    
    D --> G[攻击窗口开启]
    E --> G
    F --> G
    G --> H[攻击者可登录y次<br/>而不触发警报]
    
    style H fill:#e74c3c,color:#fff

用户研究：攻击不可检测

研究团队进行了两项用户研究（n=80和n=20），结果令人担忧：

  • 克隆检测错误消息：没有一个参与者将其与攻击联系起来，他们将其归因于"USB端口接触不良"、“密钥脏了”、“服务器故障”
  • 双重绑定攻击：在明确要求检查设置页面的情况下，20名参与者中只有3人注意到有两个安全密钥注册，其中只有1人表示会移除额外的密钥
  • 同步登录攻击：19名参与者全部完成了登录，只有1人注意到第一个弹窗显示的是"chase.com"而非"github.com"

一位参与者的话代表了普遍心态：“第二次就成功了，可能只是第一次插密钥的时候出错了。”

克隆检测：一个可以绕过的安全机制

计数器的工作原理

FIDO2使用计数器来检测设备克隆。每次认证，硬件安全密钥都会增加计数器值并将其发送给服务器。如果服务器收到的计数器值小于当前存储的值，就认为设备可能被克隆了。

NinjaLab在2021年成功克隆了Google Titan安全密钥，虽然需要10小时、价值12,000美元的设备和专业技能。但Roth等人的研究表明，某些芯片的克隆成本可以低至5欧元。

隐蔽克隆攻击

假设用户的安全密钥和服务器的计数器值都是x。攻击者在获得设备物理访问权限后：

sequenceDiagram
    participant U as 用户设备
    participant A as 攻击者
    participant C as 克隆设备
    participant S as 服务器
    
    Note over A,U: 攻击者获得设备物理访问
    A->>C: 克隆设备 (计数器=x)
    A->>U: 发送y个虚拟请求
    U->>U: 计数器增至x+y
    Note over C: 克隆设备计数器=x
    Note over S: 服务器计数器=x
    
    loop 攻击窗口 (最多y次)
        C->>S: 登录请求 (计数器=x, x+1, ...)
        S->>S: 更新计数器
        S->>C: 登录成功 ✓
    end
    
    U->>S: 用户登录 (计数器=x+y)
    Note over S: x+y > 服务器当前值
    S->>U: 登录成功 (不触发警报)
    
    Note over C,S: 攻击者已获得访问权限

攻击者现在可以使用克隆设备登录y次，而用户下次登录时不会触发警报。攻击者的登录窗口与y成正比——只要选择足够大的y，就可以获得可观的攻击窗口。

研究团队提出了一种改进的基于哈希的克隆检测算法，但需要硬件固件更新才能部署。

企业部署的现实挑战

采用障碍的质性研究

2025年发表的一项质性研究调查了德国公共管理部门部署无密码认证的障碍。研究发现，采用新技术面临的挑战包括：

  • 复杂性感知：IT部门认为实施过于复杂
  • 成本担忧：硬件安全密钥的采购和维护成本
  • 实施路径不清晰：缺乏明确的部署指南

FIDO联盟的企业研究显示，尚未部署Passkey的组织主要担忧是复杂性、成本和实施清晰度不足。这表明，教育和培训可能是比技术本身更紧迫的需求。

日本案例的启示

日本的Passkey部署提供了正面案例：

公司 用户规模 关键成果
KDDI 1300万au ID用户 客服电话减少35%
LY Corporation 2700万活跃用户 Passkey占手机认证的50%，速度是SMS OTP的2.6倍
Mercari 700万用户 Mercoin子公司自2023年3月起零钓鱼事件
NTT DOCOMO 未披露 约占账户认证的50%，钓鱼尝试显著减少

Tokyu Corporation报告称，45%的TOKYU ID用户拥有Passkey，Passkey登录速度比密码+邮件OTP快12倍。这些数据表明，一旦用户接受，效率提升是显著的。

技术改进建议

对依赖方的建议

基于研究发现，以下改进可以帮助缓解风险：

mindmap
  root((Passkey安全改进))
    通知机制
      显示密钥品牌型号
      显示已注册密钥总数
      重复注册使用不同模板
    注册流程
      添加新密钥前验证旧密钥
      提供明确的恢复路径
      限制单账户密钥数量
    错误消息
      明确说明克隆风险
      提供撤销可疑密钥选项
      引导用户检查安全设置
    Cookie管理
      缩短"记住设备"有效期
      提供设备管理界面
      异常登录主动通知

电子邮件通知增强

  • 在注册通知中高亮显示安全密钥的昵称、品牌和型号
  • 显示账户上注册的安全密钥总数
  • 对于重复注册，使用不同的邮件模板

注册流程加固

  • 在添加新的安全密钥之前，要求使用已注册的密钥进行认证
  • 为丢失密钥的情况提供明确的恢复路径

错误消息改进

  • 克隆检测错误应明确说明"检测到设备可能被克隆"
  • 建议用户检查账户的安全密钥列表
  • 提供立即撤销可疑密钥的选项

对用户的建议

  1. 注册多个认证器：不要将所有鸡蛋放在一个篮子里
  2. 定期检查安全密钥列表：确认没有不明设备
  3. 谨慎使用"记住此设备"：权衡便利性与风险
  4. 理解安全模型：Passkey的安全性依赖于设备安全，而非服务器

未解的问题

身份连续性

Daon公司在其FIDO历史回顾中提出了"身份连续性"的概念：在整个客户生命周期中，无论是通过呼叫中心、移动应用还是面对面，都能提供一致的身份验证体验。

这触及了Passkey的一个根本局限：它解决了在线认证的问题，但现实世界的身份验证场景要复杂得多。

共享账户

Netflix、家庭银行账户、企业共享账户——这些场景在Passkey世界中如何处理？Apple和部分第三方密码管理器支持Passkey共享，但这又引入了新的风险：共享对象的安全意识可能与你不同。

匿名账户

FIDO联盟的账户恢复最佳实践指出，对于匿名或假名账户，服务提供商可能无法提供基于身份验证的账户恢复机制，导致账户永久丢失。对于某些用户，这可能是他们想要的隐私保护；但对于大多数用户，这是不可接受的风险。

结语

Passkey代表了认证技术的重要进步，但安全领域没有银弹。当我们将密码替换为Passkey时，我们并非消灭了风险，而是重新分配了风险。

设备丢失的风险转移到了账户恢复流程；密码猜测的风险转移到了设备物理安全；钓鱼攻击的风险部分转移到了本地攻击；平台依赖的风险从"记住密码"转移到了"信任提供商"。

这些转移是否值得？对于大多数用户，答案可能是肯定的。Passkey确实提供了比密码更强的反钓鱼保护和更好的用户体验。但理解这些权衡，是做出明智安全决策的前提。

正如一位安全研究员所言：“Passkey的问题不在于它不好，而在于它被过度承诺。当我们停止将其视为密码的完美替代品，而开始将其视为另一种具有特定优势和劣势的认证方式时，我们才能真正有效地使用它。”

参考资料

  1. FIDO Alliance. “Passkey Adoption Doubles in 2024.” December 2024.
  2. Lassak, H., et al. “Mitigating Users’ Misconceptions About FIDO2 Biometric WebAuthn.” USENIX Security 2021.
  3. Yadav, T.K., Seamons, K. “A Security and Usability Analysis of Local Attacks Against FIDO2.” NDSS 2024.
  4. Kunke, N., et al. “Device-Bound vs. Synced Credentials: A Comparative Evaluation of Passkey Authentication.” ICISSP 2025.
  5. MDPI Applied Sciences. “Challenges and Potential Improvements for Passkey Adoption—A Literature Review.” 2025.
  6. FIDO Alliance. “Recommended Account Recovery Practices for FIDO Relying Parties.” February 2019.
  7. Daon. “A Brief History of FIDO.” August 2023.
  8. NinjaLab. “A Side Journey to Titan.” January 2021.
  9. FIDO Alliance. “The State of Passkey Deployment in the Enterprise.” February 2025.