2026年通行密钥恢复：四大平台对比

关于资金：CypherpunkGuide不投放监控型广告——没有广告网络、跟踪像素或软文。运营依靠透明的资金来源：现阶段是读者捐赠，将来会加入订阅以及符合编辑方针的联盟推广。我们面向读者，而非广告主。

通行密钥已经胜任日常登录。根据FIDO联盟2025年通行密钥指数，通行密钥的登录成功率为93%，其他方式为63%；平均登录用时为8.5秒，而非31.2秒。通行密钥也能抵御网络钓鱼：假网站无法诱使你输入可重复使用的登录秘密，因为通行密钥没有需要用户手动输入的秘密。

真正复杂的是恢复。日常登录时表现出色的凭据，到了恢复环节，仍可能依赖它背后的电话号码、邮箱账号、云服务、受信任设备或纸质恢复码。截至2026年8月1日，我审查了Google、Apple、Microsoft、GitHub、FIDO和NIST的25份官方或一手文档，并把同一个故障场景套进四套生态：你的日常手机、电脑和随身携带的硬件密钥都已丢失，只剩存放在别处的恢复资料。审查结果不是一套统一的“通行密钥恢复”流程，而是两到三次由不同主体控制的恢复；每一步都有自己的永久锁定条件。

因此，关键问题不只是通行密钥是否比短信双重身份验证更安全。双重身份验证（2FA）是密码之外的第二项身份证明；在抵御网络钓鱼方面，通行密钥确实更安全。你还必须确认：失去原设备后，能否恢复通行密钥的提供方，并且恢复接受这把通行密钥的账号。本文梳理这条依赖链，纠正搜索结果中已经出现的“Microsoft个人账号与企业账号混为一谈”问题，并给出一套恢复优先的迁移演练。阅读和操作期间，不要删除最后一种仍可使用的登录方式。

通行密钥恢复其实是两种恢复

#

恢复通行密钥有两条路：从凭据提供方取回原凭据，或先找回目标账号，再注册一把新通行密钥。两项操作往往由不同公司控制；完成其中一项，不代表另一项也会成功。

**通行密钥（passkey）**是某个网站或应用使用的加密登录凭据。网站保存公钥；你的设备或凭据管理器保存私钥。WebAuthn是通行密钥采用的网站身份验证标准，它会把凭据绑定到真实网站的域名。因此，NIST SP 800-63B-4把配置正确的WebAuthn认证方式视为可抵御网络钓鱼，而手动输入的一次性验证码不具备这一能力。

一次看似简单的登录，背后有两个主体：

• 凭据提供方负责保存或同步通行密钥。Apple“密码”与iCloud钥匙串、Google密码管理工具、Microsoft密码管理工具、第三方密码管理器、Windows Hello和硬件安全密钥都可能承担这个角色。
• 依赖方是接受通行密钥的网站或应用。GitHub是依赖方；如果你把Google或Microsoft账号自己的通行密钥保存在同一家公司那里，Google和Microsoft可以同时是凭据提供方与依赖方。

这是本次审查的第一个结论。常见对比会把Apple、Google、Microsoft和GitHub放进四个地位相同的栏目，但它们扮演的角色并不相同：在本文的比较里，Apple主要是凭据提供方，GitHub主要是依赖方。设备丢失后，这种角色错位会直接改变恢复路径。

FIDO的同步型通行密钥部署文档明确指出：同步能提高设备丢失后保住凭据的概率，但用户仍可能失去凭据提供方账号，或无法通过其恢复流程。“已同步”只说明受保护的副本存在，不代表提供方在任何情况下都能把它交还给你。

如果所有日常设备都不见了，会发生什么？

#

日常设备全部丢失后，同步型通行密钥只能经凭据提供方恢复；设备绑定型通行密钥本身已经丢失。目标账号能否保住，取决于你是否还握有一项存放在别处、并且仍可使用的恢复方式。

我把这个故障场景逐一应用到四套生态，并把证据写入可下载的通行密钥恢复审查表。这是一项文档审查，不是模拟锁号实验：我没有从真实账号中删除认证方式，你也不应为了复现结果而这样做。

下表只讨论由本人管理的个人账号。由管理员或身份提供方管理的账号——包括Google Workspace、Managed Apple Accounts、GitHub Enterprise Managed Users和Microsoft Entra身份——受各自组织政策约束，不属于这张表的范围。后文提到Entra日期，只是为了纠正搜索结果把企业安排误套到个人账号上的问题。

这张表还暴露了第二个问题：只说“我用了通行密钥”，并没有说明它存在哪里。同一个Windows提示框，可能把一把凭据保存在单机Windows Hello里，也可能把另一把存进同步密码管理器。二维码流程可能只借用手机完成当次登录，也可能把凭据留在手机里。制定恢复方案前，同时打开目标网站的通行密钥清单和提供方的凭据清单。记录凭据提供方与具体设备，不要只写网站名称。

四个平台各自怎样恢复

#

四套生态都能安全使用通行密钥，但恢复路径并不相同。存储位置、凭据提供方账号的恢复能力，以及设备之外的备份，决定一次丢失会不会变成永久锁号。

Google个人账号：别忽略密码管理工具PIN

#

Google密码管理工具可以在Android、Chrome、iPhone和iPad之间同步通行密钥。用户第一次在电脑、iPhone或iPad上创建通行密钥时，Google可能会另外创建一个密码管理工具PIN。Google的PIN说明指出，这个PIN用于在新设备上解锁通行密钥，同时让Google无法读取其中的加密数据。

给个人Google账号添加通行密钥，不会自动删除原密码、恢复信息或其他认证方式。Google的账号通行密钥指南还说明，通行密钥可以完成登录中的第二步验证。两件事要放在一起理解：一次通行密钥登录可以取代“密码加验证码”，但旧方式仍会保留为恢复选项，除非你主动删除它们。

如果忘记PIN，风险边界就会出现。Google表示，用户可以在过去用过Google密码管理工具通行密钥的非Android设备上重置PIN。如果所有符合条件的设备都试过，仍无法找回PIN，官方给出的后备方案是重置通行密钥。这会删除Google密码管理工具中的所有通行密钥，不会替你在各网站自动补发新密钥。你必须逐个恢复依赖方账号，再创建新凭据。

多数摘要会把两个步骤混成一个，我在审查表中把它们拆成了两行。Google账号恢复流程可以帮助你找回Gmail和Google账号；密码管理工具的恢复，解决的是如何解密其中的通行密钥集合。恢复Google账号本身，并不能证明你已经能解锁该集合。Google在两步验证疑难解答中说明，某些账号恢复审查需要3至5个工作日。Google于2025年为符合条件的个人账号推出了恢复联系人，但可用资格和逐步上线安排意味着：它只能算可选补充，不能当作所有账号都有的承诺。

Apple个人账号：iCloud钥匙串恢复有前置条件

#

Apple用端到端加密同步iCloud钥匙串中的密码和通行密钥：Apple服务器负责传输加密记录，但不保存可读副本。Apple的平台安全指南明确表示，即使用户无法访问自己的所有设备，钥匙串恢复也应当发挥作用。这比笼统地说“通行密钥在iCloud里”准确得多。

但这条路径有前置条件。Apple的通行密钥安全说明指出，在所有设备均无法访问时，恢复可能要求Apple账号密码、发送到登记电话号码的短信，以及设备密码。用于加密恢复的托管服务只允许10次身份验证尝试；第10次失败后，托管记录会被销毁。因此，“所有设备都丢失后仍可恢复”是一条经过设计的路径，不是无限兜底。

钥匙串恢复仍建立在Apple账号之上。标准恢复流程可能需要账号凭据、受信任电话号码、设备密码和等待期。一名账号恢复联系人可以提供6位恢复码；Apple最多允许设置5名联系人。联系人无法读取你的账号内容，只能协助身份恢复。

Apple还明确说明，账号恢复可能需要数日或更久，支持人员不能缩短等待时间。它是最后手段，不是当天就能恢复的应急通道。

启用可选恢复密钥前，必须看清它会关闭哪条恢复路径。Apple的恢复密钥说明写明：启用28个字符的恢复密钥会关闭标准账号恢复。若启用了“高级数据保护”，Apple允许恢复密钥与恢复联系人并存，并表示两者中任意一项都可能帮助你重新取得访问权限。但如果你既不知道账号密码，也没有受信任设备，无法提供恢复密钥，又没有可用的已设置联系人，Apple表示你可能会被永久锁在账号之外。恢复密钥只有存放在它所保护的Apple账号之外，才能成为你独立掌握的恢复方式。把唯一副本放进Apple备忘录、iCloud云盘或“密码”应用，会形成封闭循环；Apple明确警告不要把密钥放在这些位置。

Apple账号的实体安全密钥与iCloud钥匙串中的通行密钥是两项不同功能。Apple要求至少注册2把实体密钥，最多允许6把；其安全密钥指南警告，如果所有受信任设备和所有已注册密钥都丢失，账号可能永久无法访问。备用密钥必须事先注册、确认可用，并与日常设备分开存放，才算真正的备用。

Microsoft：个人账号不适用Entra的短信停用时间表

#

Microsoft同时支持同步型和设备绑定型通行密钥。它的个人用户通行密钥指南把同步型通行密钥定义为可通过凭据管理器恢复的凭据；设备绑定型通行密钥随设备丢失，除非另有认证方式。Microsoft密码管理工具正在向个人Edge配置文件逐步推出，而Windows Hello和实体安全密钥中的凭据可能是设备绑定型。

“Microsoft将在2026年9月停用短信”这一标题会直接影响读者的迁移决定，所以我回到Microsoft原始资料核对。2026年9月1日开始的安排针对的是Entra ID租户，也就是由组织管理的身份目录：系统会自动为已经启用短信或语音验证的用户启用通行密钥，并提示他们完成注册。租户管理员可以暂时选择退出，直到2027年2月1日Microsoft为Entra提供的短信和语音服务正式停用。Microsoft另有页面说明，个人账号的短信验证码正在逐步停用，但该消费者页面并未给出一个对所有个人账号生效的“2026年9月”截止日。把企业和个人范围混在一起，会用一个错误期限催促个人用户删除仍可用的恢复方式。

个人账号有自己的永久锁定边界。Microsoft表示，如果已经启用两步验证，而所有备用验证方式都无法访问，常规账号恢复表单和支持人员都无法帮你恢复访问。Microsoft还提供一项独立凭据：25位恢复码。其恢复码指南说明，在两步验证启用期间更改安全信息，可能需要等待30天。应在危机发生前生成并保存恢复码，而不是等通行密钥所在设备丢失后再想办法。

GitHub个人账号：恢复方式不少，但支持团队不能越权解锁

#

这里讨论的是自行管理凭据的个人账号；GitHub的通行密钥文档并未把同一恢复模型扩展到企业托管账号。对个人账号而言，浏览器登录时，GitHub允许一把通行密钥同时完成密码和2FA验证。同步型通行密钥由Apple、Google、Microsoft或其他保存私钥的提供方负责恢复；GitHub的通行密钥管理页面也要求用户回到相应提供方恢复同步凭据。即使GitHub清单里仍显示一把设备绑定型安全密钥，它也不会因此变成可恢复的凭据。

恢复链的另一端，GitHub写得很清楚。它的恢复方式文档提供16个一次性恢复码，还列出SSH密钥（用于安全连接GitHub的密钥）、个人访问令牌（PAT，一种可代替密码访问GitHub的令牌）和已验证设备等可能的身份证明。GitHub同时警告：一种方式以前用过，不代表现在一定符合恢复条件；不活跃的SSH密钥就是一个例子。因此，你必须检查它当前是否可用，不能凭印象。用GitHub接受的已验证设备或SSH密钥提交恢复请求，最多可能需要3个工作日。

对这些个人账号，最后一条边界非常明确：如果所有凭据和恢复方式都已丢失，GitHub支持团队无法恢复启用2FA的账号。其凭据丢失指南将这种损失视为永久结果。把恢复码离线保存，并在把通行密钥设为日常登录方式前，先注册不止一种认证方式。

恢复悖论：登录更强，后备通道却可能更弱

#

所谓恢复悖论，是指日常登录能抵御网络钓鱼，后备恢复却仍依赖较弱的环节。攻击者可能转而攻击邮箱、电话号码、客服流程，或有权替换通行密钥的云账号。

这不意味着通行密钥是错误选择。真正的结论是：恢复系统属于身份验证的一部分，不是藏在后台的手续。NIST的恢复指南把账号恢复视为认证器管理事件，并要求恢复机制与账号的身份保证级别相匹配。一次性恢复码的价值在于它可以独立于日常设备；如果你把它输入假网站，它本身并不能抵御网络钓鱼。

可移植性正在改善，但现在还不能把恢复方案建立在未来承诺上。FIDO于2026年3月发布了《凭据交换格式》拟议标准，用于安全导入和导出凭据。标准写出来，不代表你现在使用的两个提供方已经能转移每一把通行密钥。依赖跨提供方迁移前，先在两端核实导出与导入功能。

隐私上的取舍同样清楚。同步能降低单台设备丢失带来的风险，却把恢复集中到一个云账号。设备绑定型密钥减少对提供方的依赖，却提高了实体丢失的代价。这与我在五层数字主权审查中区分“自己运营”和“只是把信任移到另一个控制面板”属于同一个问题。先点明你要防的对手和故障，再做选择；不要只凭口号。

按恢复优先的顺序迁移

#

安全迁移先处理恢复：盘点凭据存储位置，添加一项不依赖原提供方的恢复方式，安全验证它，再把短信或密码从主要登录方式中移除或降为备用。

1. 分别记录账号与凭据提供方。 写下GitHub — Google密码管理工具，不要只写GitHub — 通行密钥。把每把通行密钥标为同步型、设备绑定型或未知。只要存储类型不明，就先不要删除任何登录方式。
2. 先加固凭据提供方账号。 同步型通行密钥能否恢复，取决于Apple、Google、Microsoft或第三方密码管理器。更新该账号的恢复邮箱、受信任电话号码、恢复联系人和独立认证方式。沿用AI时代威胁模型的做法：先明确你要防的对手，再配置控制。
3. 在该提供方之外建立一条恢复路径。 根据服务支持情况，可以打印恢复码，把第二把硬件密钥存到别处，或使用SSH密钥；使用SSH密钥时，其私钥或经过验证的备份必须保存在另一台设备上，并确认服务当前仍接受它用于恢复。唯一副本不能留在同一个云账号里。
4. 验证时不要破坏现有状态。 打开无痕窗口或另一个浏览器配置文件，开始登录并确认备用方式会出现在选项中。若服务支持非破坏性的状态检查，优先使用。若测试会消耗一个一次性恢复码，把它标为已用，并立即替换该码或重新生成整套离线副本。不要仅为演练就启动完整账号恢复、删除主通行密钥、擦除设备，或退出所有受信任会话。
5. 把恢复说明离线保存。 写明凭据提供方、目标账号、备用凭据存放位置和官方恢复网址。这与第一次Bitcoin自托管演练中的恢复排练遵循同一原则：没有验证过的备份，只能算你相信它可用，不能算已经具备恢复能力。
6. 一次只调整一个账号的旧方式。 日常登录优先使用通行密钥。只有独立路径已经成功，而且服务不强制把电话号码用于恢复时，才把短信降为备用或移除。更换手机、密码管理器、Apple/Google/Microsoft账号或安全密钥后，重新核对整条路径。

顺序会决定结果。先移除短信、以后再补备用方式，会制造一个危险空档：手机摔坏、屏幕失灵、硬件密钥丢失，或把凭据存错提供方，都可能在这段时间里造成永久锁号。安全措施应当减少可能同时失效的环节，而不是人为增加这种风险。

结论——现在应该停用短信吗？

#

日常登录可以改用通行密钥；只有另一条恢复路径在全新浏览器环境中安全验证成功后，才把短信降为备用或移除。目标是同时获得抗网络钓鱼的登录方式，以及不依赖单台设备或单一云账号的恢复能力。

日常登录的证据很强：上文FIDO数据，以及Google在2024年公布的数据——覆盖4亿个账号、超过10亿次身份验证，登录速度提高50%——衡量的都是正常使用，不是日常设备丢失后的恢复表现。

设备丢失后的结果，不由某一项产品功能单独决定。Google密码管理工具可能要求PIN；Apple可能要求账号恢复、恢复联系人或恢复密钥；Microsoft个人账号依赖备用安全信息和25位恢复码；GitHub依赖恢复码或另一项预先登记的身份证明。“已经备份到云端”这句话，会把所有这些条件一起遮住。

先处理一旦失去、后果最严重的账号。画出凭据提供方与依赖方之间的关系，把一项恢复方式存到两者之外，验证可用后再处理下一个账号。这样做比在一个下午到处点击“使用通行密钥”慢，却能让你得到抗网络钓鱼能力，避免日常设备一丢就连带失去数字身份。

常见问题

#

通行密钥比短信双重身份验证更安全吗？

#

面对网络钓鱼时，更安全。WebAuthn通行密钥绑定到真实网站域名，假网站无法收走一段可重复使用的登录秘密。短信验证码可能被用户输入假网站，也可能在SIM卡劫持后遭到截取。恢复风险要单独判断：如果服务仍允许用短信替换已丢失的通行密钥，这条恢复路径仍然承受短信本身的风险。

手机丢失后，我的通行密钥会怎样？

#

同步型通行密钥可能在你从另一台设备恢复并解锁凭据管理器后重新出现。只保存在手机上的设备绑定型通行密钥会随手机一起丢失。无论属于哪一种，能否在没有原手机的情况下找回账号，都取决于你是否还有第二项认证方式，或网站是否提供可用的账号恢复路径。

Apple、Google或Microsoft能读取我同步的通行密钥吗？

#

这些平台的文档称，通行密钥集合采用端到端加密，或受到相应保护，因此提供方拿不到可读的私钥。但这并未消除对提供方的依赖：提供方仍负责账号、同步服务、恢复规则，以及控制加密集合访问的软件。

添加通行密钥后，我应该删除密码和用于短信验证的号码吗？

#

不要立刻删除。先添加一项独立恢复方式，并在不删除任何内容的前提下，用全新浏览器环境验证它。之后，如果服务允许，而且恢复路径不依赖同一台设备或同一个提供方，再一次只移除或降低一个账号中的较弱方式。

如果所有通行密钥和恢复码都丢失，支持团队能帮我恢复账号吗？

#

不要作此假设。GitHub明确表示，如果启用2FA的账号没有任何受其认可的恢复方式，支持团队就无法恢复账号。Microsoft也说明：个人账号启用两步验证后，如果没有可访问的备用方式，其账号恢复表单无法帮你找回账号。应在损失发生前准备好独立认证方式。

来源

#

Cora Aegis

Cora Aegis在CypherpunkGuide撰写隐私优先的运营安全（OPSEC）指南。为完成本文，她用同一个场景审查四套生态：日常设备已经丢失，但异地保存的恢复资料仍在。她核对了25份官方和一手资料，并把恢复依赖关系整理成可下载的审查表。

进一步了解Cora Aegis →