2012年7月,六家科技公司——PayPal、Lenovo、Validity Sensors、Nok Nok Labs、Agnitio和Infineon——成立了一个名为FIDO(Fast IDentity Online)的行业联盟。他们的目标简单而宏大:杀死密码。
十三年后,这个目标似乎正在接近实现。2024年,FIDO联盟报告称,全球前100大网站中已有48%支持Passkeys,这一数字在一年内翻了一倍。Passkeys登录成功率达到93%,远高于传统密码方法的63%。苹果、谷歌、微软三大平台巨头已将Passkeys深度集成到各自的生态系统中。
然而,当"无密码"成为科技巨头竞相推崇的未来时,一个更复杂的问题浮出水面:消灭密码的代价是什么?
密码的终结,还是问题的转移?
密码作为认证方式存在根本性缺陷,这一点几乎没有争议。人类记忆是有限的、不精确的、容易被模式化的。典型的用户拥有数百个在线账户,但不可能为每个账户记住一个唯一的强密码。结果是密码复用——当某个服务被入侵,攻击者可以利用泄露的凭证发起凭证填充攻击(Credential Stuffing),尝试访问用户的其他账户。
钓鱼攻击则更加直接。攻击者创建一个与真实网站视觉上几乎相同的伪造页面,诱骗用户输入用户名和密码。即使用户启用了基于短信或TOTP的双因素认证,攻击者仍可以通过实时钓鱼页面中继这些验证码。
FIDO协议的核心洞察在于:与其试图让用户更聪明地使用密码,不如从根本上移除共享秘密。
公钥挑战响应:不发送秘密的认证
FIDO2协议(包括W3C WebAuthn标准和FIDO CTAP协议)的核心是公钥加密。注册时,用户的认证器(可以是硬件安全密钥或内置平台认证器)为每个网站生成一个唯一的公私钥对。私钥永远不会离开认证器——它被存储在硬件安全模块或可信执行环境中。公钥则发送给网站服务器存储。
认证过程是一个挑战-响应协议:
- 网站生成一个随机挑战值并发送给浏览器
- 浏览器将挑战值和网站来源(Origin)传递给认证器
- 认证器要求用户进行用户验证(生物识别或PIN)
- 认证器使用私钥对挑战值签名,返回签名结果
- 服务器使用存储的公钥验证签名
这个过程的关键安全属性是:私钥永远不会被传输,挑战值每次都不同,且签名绑定了网站来源。这意味着即使攻击者截获了所有通信,也无法伪造有效的认证响应。更重要的是,钓鱼攻击在技术层面变得不可能——因为伪造网站的Origin与真实网站不同,认证器会拒绝签名。
生物识别的本地真相与用户误解
当用户使用Face ID或指纹识别器进行WebAuthn认证时,一个常见的误解是:生物特征数据被发送到了网站服务器。
USENIX Security 2021发表的一项研究揭示了这一问题的严重性。研究团队让42名参与者使用生物识别WebAuthn注册和登录一个测试网站,然后调查他们对系统工作原理的理解。结果令人震惊:67%的参与者错误地认为他们的生物特征数据被发送到了网站或其他地方。
只有33%的参与者正确识别出生物特征仅存储在本地设备上。近一半的参与者认为生物特征存储在网站服务器或远程数据库中。
这种误解并非毫无来由。在密码时代,用户习惯了"我输入的东西被发送到服务器验证"这一模式。当用户看到"用指纹登录"的提示时,他们自然地将这一交互映射到已有的心智模型上。但FIDO2的工作方式完全不同:生物识别仅在本地用于解锁认证器中的私钥,网站服务器从未接触任何生物特征数据。
这个误解的后果是双重的。一方面,它可能导致隐私担忧的用户拒绝采用更安全的认证方式;另一方面,它也可能让用户对安全性产生错误信心——如果他们认为生物特征存储在"加密的服务器"上,他们可能不会意识到生物特征无法被远程窃取恰恰是系统的核心安全属性。
研究团队设计了多种通知消息试图纠正这些误解,发现强调"您的指纹/面部数据从未离开您的设备"的消息效果最好。但即使在看到这些通知后,关键误解仍然部分持续——这表明单一的通知消息不足以完全教育用户。
同步Passkeys:便利与安全的重新定义
传统上,FIDO认证器被设计为设备绑定的——私钥存储在特定硬件上,无法被复制或传输。这带来了一个根本性的可用性问题:如果用户丢失了安全密钥,或手机损坏,他们可能面临永久失去账户访问权的风险。
Passkeys代表了一个重大转向:它允许凭证在用户的多个设备间同步。
苹果的iCloud Keychain、谷歌的Google Password Manager和微软的生态系统都实现了Passkeys同步功能。当用户在一台设备上创建Passkey时,私钥被端到端加密后同步到云端,然后分发到用户的其他设备。这意味着即使用户丢失了某台设备,他们仍可以在其他设备上访问账户。
这种设计的代价是什么?
2023年发表在arXiv上的一项研究系统分析了FIDO2的本地攻击面,揭示了同步Passkeys引入的新风险。研究团队发现了四类底层缺陷:
1. 浏览器扩展可访问的FIDO2消息缺乏机密性和完整性保护
恶意或被入侵的浏览器扩展可以拦截和修改FIDO2通信。研究团队证明了多种攻击的可行性,包括:
- 错误绑定攻击(Mis-binding):在注册过程中,攻击者将用户的公钥替换为攻击者的公钥,导致网站实际上注册了攻击者的认证器而非用户的。
- 双重绑定攻击(Double-binding):攻击者在注册用户认证器的同时,秘密注册第二个攻击者控制的认证器。
- 同步登录攻击:当用户尝试登录某网站时,攻击者在后台发起另一个网站的认证请求,用户可能无意中授权了攻击者的登录会话。
研究分析了Chrome网上应用店的211,026个扩展,发现105,381个(约50%)拥有执行这些攻击所需的权限。其中404个扩展拥有超过100万用户。
2. 克隆检测算法存在缺陷
FIDO2使用计数器机制检测设备克隆。每次认证后,认证器递增计数器;服务器验证接收到的计数器大于之前存储的值。如果攻击者克隆了设备,两个设备会产生冲突的计数器值。
但研究团队发现了一种"隐形克隆攻击":攻击者在获取设备物理访问权后,可以先发送多个虚拟认证请求预增计数器,然后克隆设备。这样,合法用户在一段时间内登录不会触发克隆检测告警,攻击者获得了隐蔽访问窗口。
3. 用户对错误消息和社会工程的误解
克隆检测触发的错误消息在大多数网站上都是通用的:“安全密钥验证失败"或"无法连接到您的安全密钥”。用户几乎无法将这些消息与潜在的设备克隆联系起来。研究中,没有任何参与者将克隆检测错误识别为攻击迹象——他们归因于USB连接问题、密钥损坏或网站故障。
4. Cookie生命周期问题
许多网站在用户选择"记住此设备"后会设置长期Cookie,跳过后续登录的2FA要求。攻击者可以窃取这些Cookie并完全绕过FIDO认证。研究显示Facebook的"记住此设备"Cookie有效期约两年。
平台生态系统锁定的困境
Passkeys的同步机制带来了一个更深层的问题:平台依赖。
当用户在iPhone上创建Passkey时,它被同步到iCloud Keychain。当用户在Android设备上创建Passkey时,它被同步到Google Password Manager。这两种生态系统之间的迁移并不直接。
理论上,用户可以通过扫描QR码在另一生态系统的设备上认证。但这种方法需要两台设备同时可用,且每次登录都需要重复这一过程。更根本的是,用户的Passkeys分布可能变得碎片化:某些账户的凭证在苹果生态,某些在谷歌生态,某些在微软生态。
企业环境面临更复杂的挑战。BYOD(自带设备)场景下,员工的Passkeys可能绑定到个人Apple ID或Google账户。当员工离职时,企业如何确保这些凭证被正确撤销?如果员工使用个人设备的生物识别创建了Passkey,企业是否能够审计或控制这些凭证?
FIDO联盟试图通过设备绑定Passkeys(Device-bound Passkeys)解决这些问题。与同步Passkeys不同,设备绑定Passkeys的私钥不能跨设备同步,类似于传统硬件安全密钥的模型。但这又回到了可用性的根本问题:如果用户丢失设备,如何恢复账户访问?
认证器安全级别的分层
FIDO联盟定义了多个认证器安全认证等级,但大多数用户可能并不了解这些等级的存在和含义:
Level 1 (L1):基本的密码替代方案。认证器通过自我声明满足安全要求,不需要第三方审计。大多数主流硬件安全密钥仅达到L1级别。
Level 2 (L2):要求认证器在受限操作环境(Restricted Operating Environment)中运行安全相关操作。需要安全实验室的设计文档审查。
Level 3 (L3):针对物理攻击提供更强保护。需要完整的安全评估,包括渗透测试。
Level 3+ (L3+):最高安全级别,要求针对高级物理攻击的额外保护。
这个分层体系的现实意义在于:不同威胁模型需要不同级别的认证器。对于普通消费者,L1级别的认证器已足够抵御远程攻击;但对于高价值目标或企业环境,可能需要L3+级别的设备。
然而,认证等级信息在用户界面中几乎不可见。用户在注册Passkey时不会看到任何关于认证器安全等级的提示。2024年Reddit上的讨论揭示了一个有趣的事实:YubiKey——最流行的硬件安全密钥之一——仅通过FIDO2 L1认证。这引发了关于"足够安全"定义的辩论。
恢复机制的空白
密码系统有成熟的恢复机制:忘记密码可以通过电子邮件、短信或安全问题重置。但在无密码世界中,如果用户丢失了所有认证器,恢复路径是什么?
FIDO联盟的指南建议用户注册多个认证器以避免账户锁定。但这将问题推给了用户:他们需要主动管理多个设备的冗余,并确保这些设备不会同时丢失或损坏。
企业部署中,账户恢复通常通过管理员干预解决。管理员可以为用户注册新的认证器或撤销丢失的凭证。但这要求企业维护适当的身份验证流程,以确认请求恢复的用户确实是账户所有者。
一个更深层的挑战是:如果Passkeys绑定到用户的个人设备,而用户更换了所有设备,他们如何证明自己是账户的合法所有者?传统密码系统中,密码是一个共享秘密,用户知道它即可证明身份。在无密码系统中,身份证明依赖于认证器的持有——一旦认证器丢失,这一证明路径就断裂了。
2023年,Palantir在部署FIDO2强制认证后分享了他们的经验:“新员工、丢失密钥与学到的教训”。他们发现,即使是技术熟练的员工,也会遇到各种意外情况导致账户锁定,而恢复过程往往比预期复杂。
统计数据的另一面
FIDO联盟2025年发布的数据显示积极趋势:Passkeys登录成功率为93%,远高于传统方法的63%;企业采用Passkeys的比例达到87%;消费者对Passkeys的认知度从2022年的39%上升到2024年的57%。
但这些数字需要仔细解读。登录成功率高部分源于Passkeys消除了密码输入错误和忘记密码的情况——一旦用户拥有有效凭证,登录几乎是确定性的。但这不意味着用户完全理解系统的安全属性或能够正确应对异常情况。
企业采用率高反映的是平台推动和合规要求,而非用户主动选择。许多企业将Passkeys作为默认或强制的认证方式,用户可能没有真正"选择"使用它们。
更重要的是,这些统计数据几乎没有触及核心问题:当Passkeys成为主要认证方式时,用户是否能够在异常情况下保护自己的账户?他们是否理解自己的凭证如何被同步、存储和保护?
技术改进的路径
面对这些挑战,技术社区正在探索多种改进方向:
改进的克隆检测算法:研究者提出了基于挑战哈希链的克隆检测方案。认证器存储最近接收的挑战哈希,并在响应中返回;服务器维护一个有序的挑战哈希列表。这种方法可以更精确地检测克隆攻击,而不会因为网络延迟或丢包产生误报。
增强的认证器证明(Attestation):企业可以要求用户提供认证器的证明,验证其型号和安全等级。但这引入了隐私顾虑——证明可能允许网站跨站点追踪用户。FIDO联盟正在探索平衡安全验证与隐私保护的方案。
跨生态系统凭证导出:目前,Passkeys在不同平台间的迁移仍然有限。W3C和FIDO联盟正在讨论标准化的凭证导出格式和协议,但这涉及复杂的技术和政治协商。
改进的用户教育:USENIX研究表明,简单的通知消息可以部分纠正用户误解,但不足以完全解决问题。更有效的方案可能包括交互式教程、渐进式披露或首次使用时的引导流程。
权衡的本质
无密码认证并非万能药,而是一种权衡。它在某些维度上明显优于密码——抗钓鱼、抗凭证填充、减少用户记忆负担——但在其他维度上引入了新的挑战——设备依赖、平台锁定、恢复复杂性。
理解这些权衡对于做出明智的认证策略决策至关重要。对于高安全场景,硬件安全密钥配合传统密码可能仍是最佳选择。对于普通消费者,同步Passkeys可能提供了便利性和安全性的合理平衡。对于企业,混合策略——结合设备绑定和同步Passkeys、预留恢复路径、定期审计凭证——可能更合适。
密码的终结或许正在到来,但取代它的不是一种更简单的方案,而是一组需要用户、开发者和企业共同理解和管理的复杂技术与策略。认识到这一点,或许是无密码时代真正的开端。
参考资料
-
Lassak, L., Hildebrandt, A., Golla, M., & Ur, B. (2021). “It’s Stored, Hopefully, on an Encrypted Server”: Mitigating Users’ Misconceptions About FIDO2 Biometric WebAuthn. USENIX Security Symposium.
-
Yadav, T. K., & Seamons, K. (2023). A Security and Usability Analysis of Local Attacks Against FIDO2. arXiv:2308.02973.
-
FIDO Alliance. (2024). FIDO Authenticator Security Requirements v1.5.
-
FIDO Alliance. (2025). FIDO Alliance Passkey Index.
-
W3C. (2021). Web Authentication: An API for accessing Public Key Credentials - Level 2.
-
Lyastani, S. G., Schilling, M., Neumayr, M., Backes, M., & Bugiel, S. (2020). Is FIDO2 the Kingslayer of User Authentication? IEEE S&P.
-
Google Security Blog. (2022). Security of Passkeys in the Google Password Manager.
-
Apple Support. (2024). About the security of passkeys.
-
JumpCloud. (2025). Passwordless Authentication Adoption Trends.
-
Corbado. (2025). Enterprise Passkey Deployment Challenges & Solutions.