Passkey 如何取代密码

登录背后的验证换轨

想象一个很普通的早晨。你在厨房准备早餐，手上沾着水，平板忽然要求重新登录。密码时代的动作很熟悉：回忆密码，打开密码管理器，复制一串字符，再切到短信或邮箱寻找验证码。任何一步出错，都可能让人放弃登录，或者干脆把密码改得更短、更容易记。使用 Passkey 时，屏幕可能只要求你在手机上确认，或者用指纹、面容、设备口令批准一次操作。几秒钟后，账户打开了。表面变化是步骤减少，底层变化却是网站验证你的方法已经换轨。过去，网站等待你交出一段双方共同依赖的秘密。现在，网站先发出一份临时挑战，持有私钥的认证器为这份挑战签名，网站使用早已登记的公钥检查结果。登录凭据的核心部分留在认证器一侧。它可能位于手机或电脑，也可能位于硬件安全密钥，或者由凭证管理器承载。攻击者面对的目标随之改变。骗走一个字符串、从数据库取得密码、把同一密码拿到别的网站尝试，这些传统路径被明显压缩。新的重点转向四个位置：服务端有没有严格执行协议，私钥出现在哪些设备上，新设备怎样进入同步体系，以及用户丢失全部设备后怎样恢复账户。理解 Passkey，不能只看登录按钮少了几步。真正值得追踪的是账户控制权如何建立、如何移动，又如何被重新授予。

FIDO2 与公钥认证

Passkey 建立在 FIDO2 体系上。这个体系里有两个核心组件。WebAuthn，全称 Web Authentication，规定浏览器或客户端怎样与网站进行公钥认证。CTAP 负责客户端与认证器之间的通信。认证器可以集成在手机和电脑里，也可以是一枚独立的硬件安全密钥。注册 passkey 时，认证器针对目标服务生成一组配对密钥。公钥交给网站保存，私钥留在设备、硬件安全密钥或凭证管理器一侧。这里的配对关系很重要：公钥负责检查，私钥负责产生证明。公钥可以交给服务端，服务端凭它验证签名；要生成有效签名，仍需调用对应的私钥。登录开始后，网站生成挑战值。可以把它理解为当前会话的一道临时题目。认证器针对这次挑战完成签名，网站再使用账户登记过的公钥验证。下一次登录会有新的挑战，先前的响应无法直接拿来完成新的验证。另一把私钥生成的签名，也无法通过当前公钥的检查。于是，登录从提交一个长期有效的秘密，改成了对一次性问题给出密码学证明。用户看到的动作可能只是触碰传感器，协议处理的却是账户、公钥、私钥、挑战和签名之间的对应关系。

本地解锁与远程验证

设备解锁和网站认证处在两个层次。指纹、面容或设备口令通常用于批准本地调用，让设备确认当前有人可以使用这枚凭证。网站得到的是凭证标识、签名和相关认证数据。网站不需要取得用户的指纹模板，也不需要知道设备口令。举个听得见的例子：一扇门可以要求门卫先确认来访者，再让保险柜里的印章盖在文件上。远处收到文件的人检查印章，却看不到门卫采用了哪种确认方法。Passkey 的本地确认与远程验证也可以这样分开理解。手机负责决定是否允许本次签名，网站负责判断签名是否来自账户登记的凭证。网站数据库因此保存验证材料，而不是能够生成签名的私钥。数据库泄露仍然是严重事件，服务方仍需调查和处置。可攻击者拿到公钥后，主要获得的是检查签名的能力。公钥本身无法完成下一次挑战。这与密码数据库的风险结构存在根本差异。密码是共享秘密，服务方必须用某种形式验证用户提交的相同秘密。Passkey 则把生成证明的能力留在认证器一侧，把验证能力交给网站。

抗钓鱼来自来源绑定

公钥认证还要回答一个关键问题：这把钥匙究竟为谁服务？如果任何页面都能随意调用同一凭证，仿冒网站仍可能把用户拉进错误场景。WebAuthn 使用 RP ID 和 origin 建立凭证的使用范围。RP 是 Relying Party，也就是依赖认证结果的服务方。RP ID 可以理解为服务方在 WebAuthn 里的身份范围。origin 描述网页来源，由协议、域名和端口共同界定。浏览器、客户端和认证器依据这些信息，判断当前页面是否处于凭证允许的范围。假设攻击者复制了银行或代码托管平台的登录页。字体、颜色、标志和按钮都做得很像，页面甚至可以催促用户尽快操作。密码登录依赖用户把字符串交给页面。字符串进入攻击者控制的网页后，可能被转发到真实服务。Passkey 的交互改变了这条链路。仿冒页面的来源与真实服务存在差异，认证器会依据服务身份限制凭证调用。用户手里也没有一段可以抄写或转交的 passkey 字符串。传统钓鱼最擅长利用人的匆忙与信任，而来源绑定把一部分判断交给浏览器、认证器和协议规则。页面看起来多像，无法改变它实际来自哪个来源。

切断跨站复用

来源绑定还压缩了跨站凭证复用。密码时代，一名用户可能把同一密码用于多个网站。只要其中一家泄露，攻击者就能把相同字符串带到其他服务尝试。Passkey 为服务登记公钥凭证，凭证的使用又受到 RP ID 和 origin 约束。一家网站保存的公钥无法拿去生成另一家网站所需的签名。这里被切断的是一条常见传播链：同一个秘密在人、设备、网站和多次会话之间反复流动，最终在某处泄露，再被拿到别处验证。可以把密码想成一把被复制很多次的通用钥匙。Passkey 更像每个服务各自登记一套验章规则，用户设备保管相应的印章。某个服务的验章记录外泄，不会让攻击者获得盖章能力，也不会自然打开另一个服务。这个比喻只帮助理解结构，真实系统仍要依赖浏览器、认证器和服务端共同执行 WebAuthn。抗钓鱼来自来源绑定、公钥验证和一次性挑战的组合，并非来自某一个界面按钮。服务支持 Passkey，只能说明它开始使用这套能力。安全强度还要看每个环节是否把规范要求落到实际代码中。

服务端校验决定协议边界

服务端校验是这套机制的边界之一。服务方需要精确验证 origin、RP ID、挑战值和签名。挑战值应当对应当前认证会话。签名检查确认响应匹配账户登记的公钥。RP ID 与 origin 的检查则确认这份响应服务于预期网站。假设服务端对 origin 采用过宽的接受范围，浏览器提供的来源信息就失去了应有的筛选作用。再假设挑战管理与会话脱节，一份原本合法的响应便可能被接入错误流程。WebAuthn 在客户端建立的约束，需要服务端完成最后核验，才能形成闭环。W3C 还指出另一类边界：可信域内部的恶意代码。如果服务方自己的域名下已经运行攻击者控制的代码，请求可能仍带着符合预期的来源信息。外部仿冒网页和可信域内部失守属于两种攻击面。来源绑定对前一种情况很有力量，后一种情况则要求服务方继续保护域内代码、认证页面和后端逻辑。因此，看到页面出现“使用 Passkey”按钮时，可以继续追问：注册和登录是否严格验证来源，挑战是否与会话绑定，签名是否用正确公钥核验，承载认证的可信域是否得到保护。Passkey 能显著减少传统钓鱼、共享秘密泄露和跨站复用。后端校验错误与域内代码风险仍需独立防守。

同步型与设备绑定型

接下来要区分 Passkey 的两种重要存储形态。第一种是同步型 passkey，也叫 synced passkey。它可以通过云端生态或第三方凭证管理器进入多台获准设备。第二种是设备绑定型 passkey，也叫 device-bound passkey。它留在创建它的设备或硬件安全密钥中。两种形态都可以通过 WebAuthn 完成公钥认证，差异集中在私钥分布与新设备获得调用能力的方式。同步型凭证适合多设备生活。用户今天在手机上注册，明天可能在同一同步体系里的电脑上使用。旧手机损坏后，只要同步体系能够安全确认用户和新设备，账户访问更容易延续。同步因此提供两类直接价值：一类是便利，减少重复注册；另一类是冗余，降低单台设备遗失造成的中断。可用性改善还可能减少用户保留弱密码的动力。很多人之所以舍不得密码，并非喜欢输入字符串，而是担心唯一设备损坏后彻底失去账户。同步型凭证试图解决这个现实问题。

同步带来的风险重分配

便利也会扩大需要审查的控制面。使用同步型 passkey 时，安全评估要加入同步服务账户、终端解锁、新设备批准和同步实现。攻击者的兴趣可能从某个网站的密码，转向承载多枚凭证的同步账户。这里适合用“风险重新分配”来理解。凭证不再依赖单台设备，设备故障风险下降；同步体系拥有更大的协调能力，它的账户保护和设备准入因而更加重要。假设一名用户有手机、平板和电脑。正常情况下，多台设备带来冗余，其中一台损坏不会中断账户。异常情况下，如果攻击者能够把自己的设备加入同一同步体系，风险可能同时影响多项凭证。评估重点便从“云端有没有数据”进一步深入到“谁能批准设备”和“批准之后能做什么”。同步本身描述的是凭证能否跨设备可用。同步质量则由一系列控制共同决定：同步账户如何登录，新设备怎样获准，旧设备如何撤销，终端解锁后能够调用哪些凭证，以及账户恢复是否会给陌生设备授予同等能力。

同步加密与设备准入

凭证可以跨设备出现，没有直接回答同步服务能否读取私钥。前者描述可迁移性，后者取决于加密架构和密钥管理方式。Apple 对 iCloud Keychain 的说明是，其中保存的密码和 passkey 使用端到端加密，Apple 服务器无法读取内容。这项声明适用于 Apple 的具体架构。检查其他云端生态和第三方凭证管理器时，需要分别查看各自设计。可以把同步安全拆成三个层次。第一层是内容保护：服务器上的同步数据怎样加密，哪些设备或账户实体拥有解密能力。第二层是账户保护：谁能够进入凭证同步账户，账户本身依赖哪些认证和恢复方式。第三层是设备准入：一台新手机或新电脑满足什么条件后，可以进入同步体系并调用凭证。端到端加密重点回答第一层。第二层和第三层仍然决定攻击者能否沿着被系统认可的路径获得使用能力。一个攻击者可能看不到服务器上的裸露私钥，却通过同步账户恢复，把自己的终端登记成获准设备。此后，他从合法设备路径调用凭证，造成的账户影响仍然很大。因此，产品写着“端到端加密”是重要信息，还应继续观察新设备批准、遗失设备撤销和同步账户恢复。三层共同构成同步型 passkey 的现实边界。

设备绑定与备用认证器

设备绑定型 passkey 采用更收敛的分布方式。私钥留在创建它的终端或硬件安全密钥，不进入跨设备同步。要使用这枚凭证，通常需要接触承载它的设备，并通过对应的本地调用控制。对于希望明确限定凭证位置的账户，这种设计便于盘点。管理者可以知道某枚凭证位于哪台设备，或者位于哪一枚安全密钥。同步服务账户也不会因为同步机制而获得同一枚凭证的调用能力。这种边界通常更强，代价主要出现在设备故障、遗失和人员变动时。一枚安全密钥损坏，一台设备永久丢失，或者持有设备的员工离开岗位，都可能要求重新建立访问能力。如果账户只有一枚设备绑定凭证，故障很容易把用户推入恢复流程。稳妥做法是在问题发生前登记备用认证器。备用凭证可以位于另一台独立设备或另一枚硬件安全密钥，并由账户主人或组织按既定方式保管。FIDO 对设备绑定型 passkey 给出的方向，包括备用认证器和风险分级的恢复路径。设备绑定把凭证范围收紧，也把冗余规划变成部署工作的一部分。

按账户场景选择边界

同步型与设备绑定型之间，没有脱离场景的单一答案。两者面对的主要失败后果不同。同步型方案关注同步账户失守、新设备被错误批准，以及终端解锁控制不足。设备绑定型方案关注唯一设备损坏、备用认证器缺失，以及紧急恢复被迫降低门槛。可以设计两个假想账户来比较。第一个是普通消费账户，用户频繁换机，同时使用手机和电脑。同步型 passkey 能减少重复登记，也能降低单个设备遗失造成的中断。第二个是高价值管理账户，使用者数量有限，组织能够妥善保管多枚硬件安全密钥。设备绑定型凭证配合备用认证器，可以提供更清楚的控制范围。真正的问题不是给两种形态排出永久名次，而是确认账户面临什么威胁、用户能管理多少认证器、服务能否执行严格恢复，以及哪一种故障后果更难承受。对普通用户，过度复杂的设备管理可能促使他们保留弱密码。对高价值账户，模糊的同步准入可能扩大攻击面。安全设计需要把技术强度与用户能否持续执行放在一起衡量。

二维码跨设备认证

用户还会遇到一种看起来很像同步的体验：在电脑上打开登录页面，屏幕出现二维码，随后用手机扫描并确认。这里发生的是跨设备认证。电脑没有目标 passkey，附近的手机持有凭证，两台设备围绕当前登录请求协作。此类流程通常加入邻近性检查，用来确认参与认证的设备处于合理距离。真正进行私钥运算的仍是持有凭证的手机。远程网站取得完成验证所需的签名响应。二维码承担会话连接和设备协作入口，它不负责把私钥交给网站。可以用一次出差场景理解：你在临时电脑上访问账户，电脑发起登录，手机识别二维码并批准签名。网站验证成功后，为电脑上的当前会话放行。手机像是随身携带的签字设备，临时电脑负责展示文件和接收结果。网站看到签名，临时电脑没有因此获得手机中的私钥。

临时协作与长期注册

区分跨设备认证与同步，可以观察登录结束后的状态。关键问题是：电脑是否已经获得一枚以后能够独立调用的凭证？如果没有，电脑只是借助手机完成当前会话。下次登录时，它仍可能需要手机参与。如果服务随后邀请用户在电脑上创建新的 passkey，那属于新的凭证注册。新注册会改变凭证分布，服务端应像处理其他登记操作一样，确认当前账户控制权、目标 RP ID、来源和登记结果。对普通用户来说，两种流程都可能表现为“手机帮电脑登录”。对安全审查人员来说，它们承担不同功能：同步使凭证进入多台获准设备；跨设备认证让一台没有该凭证的终端借助附近设备完成一次认证。前者影响长期分布，后者解决当前协作。使用公共电脑或陌生终端时，用户还可以观察服务是否在认证后建议创建长期凭证，以及当前终端是否被加入可信设备。二维码出现，只说明附近设备正在参与。长期权限是否变化，要看后续注册和设备管理记录。

恢复入口决定安全下限

现在把视线从登录正门移到找回账户的入口。很多系统在日常登录时使用 passkey，设备遗失后却允许用户通过短信、邮箱链接、人工客服或其他方法恢复控制权。攻击者会选择成功率最高的路径。他无须攻破 WebAuthn，也无须从认证器提取私钥。只要恢复系统相信他是失去认证器的账户主人，他就可能建立新的登录能力。恢复困难来自真实需求：合法用户确实可能同时失去手机、电脑和安全密钥。服务方必须在可用性与冒名风险之间做决定。短信的强度取决于号码控制权，邮箱链接的强度取决于邮箱账户本身，人工客服则依赖身份核验规则和执行一致性。任何恢复方法一旦有权更换认证方式、登记新设备或创建新 passkey，它就参与了账户控制权的分配。日常登录再强，也无法单独弥补恢复入口的宽松。账户的现实防护水平，会向攻击者能够利用的最弱入口靠拢。

把恢复纳入正式设计

同步型 passkey 可以减少一部分恢复事件。用户丢失单台设备后，另一台获准设备仍可能取得同步凭证，于是无须立刻进入短信、邮箱或客服流程。这提升了可用性，也让同步账户自身的恢复质量变得关键。设备绑定型凭证则可以通过多个预登记认证器建立冗余。主安全密钥丢失时，备用密钥先恢复正常访问，用户随后撤销遗失凭证并登记替代设备。这样的路径使用事先建立的强认证关系，通常比事后临时证明身份更清楚。仍需人工处理时，风险分级比所有账户使用同一门槛更合适。账户价值较高、登录位置异常、设备历史缺失或证明材料薄弱时，可以提高审核强度。FIDO 建议设备绑定型 passkey 使用备用认证器或风险分级的恢复路径，核心就是让恢复成为正式设计，而不是事故发生后的临时补丁。服务方需要明确恢复能够执行哪些操作，恢复完成后能否立即登记新 passkey，以及原有设备会不会收到可见的账户变化记录。

正确实施的四层结构

NIST 在二〇二四年针对 SP 800-63B 发布补充指南，讨论可同步认证器。NIST 的判断是，正确实施的 syncable authenticator，包括 FIDO passkey，可以提供抗钓鱼认证，并改善跨设备使用与账户恢复。这个表述肯定了同步凭证的价值，同时把实现质量放在前提位置。可以用四层结构理解“正确实施”。第一层是协议验证：服务端处理 RP ID、origin、挑战值和签名。第二层是凭证形态：私钥进入同步体系，或者留在指定设备。第三层是终端与账户控制：谁能解锁凭证，谁能批准新设备，谁能撤销旧设备。第四层是恢复：原有认证器全部不可用时，服务怎样重新判断账户归属。四层的失败模式各不相同。协议层失误会削弱来源绑定；同步账户失守会扩大凭证使用范围；设备绑定凭证缺少冗余会造成访问中断；宽松恢复会给远程冒名者留下旁路。把四层放在一起，才能看见一个 passkey 部署的完整安全边界。

规模采用与标准状态

大规模采用已经从概念验证走向真实平台。GitHub 在二〇二四年披露，自二〇二三年七月开放 passkey 公测后，平台已经注册接近一百四十万个 passkey。这个数字说明大型服务能够把公钥凭证交付给大量真实用户，也说明浏览器、设备和网站之间的协作已经具备规模。它回答的是采用量问题。不同平台仍可能采用不同的同步生态、备用凭证策略和账户恢复门槛。标准状态也要按官方页面分别观察。WebAuthn Level 3 的规范文本已经定义 discoverable credentials，也就是可发现凭证，passkey 属于这一类。W3C 新闻页面称 Level 3 在二〇二六年成为 Recommendation。当前可检索到的规范摘要页面仍标记为二〇二六年五月二十六日的 Candidate Recommendation Snapshot。下一步观察指标很明确：规范页的状态标签、版本链接和新闻公告是否指向同一发布记录。对于正在部署的服务，更直接的工作是按照规范文本检查注册、认证、来源验证和凭证管理流程。

迁移整个账户生命周期

假设你负责一家服务从密码迁移到 passkey，最容易出现的情况，是只在旧登录系统旁边增加一个新按钮。用户注册了公钥凭证，账户里仍保留弱密码；重置入口继续发送邮箱链接；客服凭几项容易取得的信息就能更换认证方式；同步账户又缺少清楚的新设备批准机制。这样的系统改善了部分登录体验，也关闭了部分传统钓鱼路径，可攻击面仍散落在旧入口。更完整的迁移要覆盖账户生命周期。注册阶段要确认来源、账户状态和新凭证。日常认证阶段要严格处理挑战、RP ID、origin 与签名。设备管理页面要展示已登记凭证，允许用户识别并撤销遗失设备。高价值账户要安排备用认证器。恢复阶段要根据风险重新授予控制权。迁移期间还要观察旧密码承担哪些任务，哪些用户尚未建立足够的凭证冗余，以及恢复请求是否暴露某种设备或生态依赖。攻击者通常沿着成本较低的一套规则行动。新旧两套入口同时存在时，较弱的一套会持续影响整个账户。

个人账户检查清单

个人用户也可以用一个具体清单检查自己的安排。先确认高价值账户使用同步型凭证、设备绑定型凭证，还是两者并存。使用同步型方案时，查看同步账户怎样保护，新设备如何获准加入，遗失设备能否撤销。使用设备绑定型方案时，准备第二个认证器，避免唯一设备损坏后立刻进入高风险恢复。接着打开账户的设备和凭证管理页面，确认自己能够辨认每一枚凭证。然后检查恢复设置：短信、邮箱和客服分别拥有多大权限，恢复完成后能否直接登记新 passkey。最后设想一次最糟的情况：手机、电脑和安全密钥同时无法使用，谁来重新授予账户，服务会要求什么证据？这个检查过程不要求用户掌握每个密码学细节。只要持续追踪三个问题就很实用：私钥能由哪些设备调用，谁能批准新设备，全部设备丢失后谁有权恢复账户。它们分别对应凭证分布、同步准入和恢复权力。

账户控制权的连续管理

当密码输入框逐渐从常用服务中消失，人们最先感受到的可能只是登录更快。真正决定长期结果的工作发生在后台。服务方要让注册、认证、同步、设备管理、撤销和恢复遵循同一套账户控制逻辑；用户则要知道自己的凭证分布在哪里，备用路径由谁掌握。接下来值得持续观察的信号包括：服务是否说明同步型与设备绑定型选项，新设备加入是否有清楚的确认步骤，用户能否查看并撤销凭证，恢复流程是否维持抗钓鱼强度，以及 WebAuthn Level 3 的官方页面状态何时统一。成熟的 passkey 产品会在注册时帮助用户安排冗余，在设备变化时留下可见记录，在高风险恢复时提高证据要求。密码时代的核心问题是怎样保守一段共享秘密。Passkey 时代的核心问题变成了谁持有凭证、谁能批准设备，以及谁有权重建账户。登录按钮只是入口，连续管理账户控制权，才是这场迁移真正的安全工程。