通行密钥回退与恢复：标识符优先策略

1. 简介#

通行密钥已发展成为传统身份验证方法的真正替代方案，支持通行密钥的设备接近 95%。然而，即使是最先进的系统也需要有效的回退和恢复策略，以应对通行密钥无法访问（回退）甚至丢失（恢复）的情况。本指南旨在探讨需要回退和恢复的各种情况，并讨论可能的解决方案。

在考虑回退和恢复方法时，重要的是要使它们的强度与主要身份验证方法的强度相匹配。本指南将区分通行密钥的不同用法，特别关注通行密钥被用作独立的 MFA 的上下文，以适当地定制回退和恢复方法。

关键问题：

• 存在哪些回退方案？ 通行密钥系统可能发生哪些潜在的回退情况，以及应该如何处理它们以维护安全性？
• 应该如何处理恢复？ 根据通行密钥的使用模式，特别是在使用 MFA 的环境中，应该如何设计恢复流程以确保其安全性？

通过探讨这些问题，本指南将为产品经理和开发人员提供有效设计、实施和管理通行密钥系统所需的见解，确保安全性不会以牺牲用户体验为代价。

2. 定义：标识符、安全级别与回退和恢复#

在深入研究回退和恢复策略之前，重要的是要对我们将使用的一些基本术语建立清晰的理解。

2.1 标识符：电子邮件、电话号码和用户名#

在大多数业务和消费者系统中，身份验证依赖于三个主要标识符：电子邮件、电话号码和用户名。

绝大多数系统使用电子邮件作为主要标识符，特别是在基于 Web 的应用程序中。然而，移动优先或应用优先的平台通常更喜欢使用电话号码作为标识符，因为基于短信的 OTP（一次性密码）很容易自动填充。在某些情况下，除了这些标识符之外，用户可能还需要设置用户名，主要是针对需要唯一显示名称的平台。还有一种日益增长的趋势，特别是在较大的平台上，允许使用电子邮件和电话号码来增加灵活性。

在初始注册期间，这些标识符通常通过确认链接 / OTP（用于电子邮件）或 OTP（用于电话号码）进行验证，确保该标识符属于正确的人。在失去访问权限的情况下，证明对先前验证过的电子邮件或电话号码的控制权通常足以恢复帐户访问。由于这些标识符是与用户最可靠的通信形式，电话号码通常被收集用于 MFA（多因素身份验证）目的，而短信则是常用的第二因素。

在需要面向公众标识符的系统中（例如社交媒体、论坛或某些专业平台），通常使用用户名来提供额外的用户身份层。虽然它们在身份验证中不能发挥与电子邮件或电话号码相同的功能作用，但用户名可以在公共或点对点上下文中为用户提供可识别的身份。然而，它们引入了额外的复杂性，因为用户经常会忘记它们，并且在大多数情况下，需要用户名以及另一个标识符。因此，在本文中，我们将不关注用户名。

其他 2FA 选项（例如生成 TOTP 代码的身份验证器应用程序）不依赖于标识符，但对于普通用户来说通常更难设置。通行密钥也引入了无需标识符即可工作的可能性（无用户名身份验证），这一功能在加密领域越来越受欢迎。然而，对于消费者和商业解决方案而言，出于回退或恢复目的与用户通信（通常通过电子邮件）的需求，使得无用户名系统的实用性较低。

2.2 安全级别：单因素身份验证 (SFA) 与多因素身份验证 (MFA)#

单因素身份验证 (SFA) 系统是依靠一种形式的身份验证来验证用户身份的系统。通常，这个单一因素是密码，但它也可以是社交登录、电子邮件 OTP 或任何只需一种类型证明的方法。如今网络上的大多数系统都是 SFA 系统。然而，安全方面存在一个众所周知的权衡。在集成通行密钥时，它们通常作为传统密码的附加组件或替代品，从而提高了系统的便利性。对于此类系统，通常仍然允许诸如电子邮件 OTP 或社交登录之类的回退选项，这通过减少密码的使用来改善用户体验，但并不会将系统的安全性提升到 SFA 级别以上。

多因素身份验证 (MFA) 涉及两个或多个独立的因素来验证用户的身份；这就是它比 SFA 更安全的原因。这些因素可能包括用户知道的信息（密码或 PIN 码）、用户拥有的物品（安全令牌或移动电话应用程序）以及用户自身的特征（如指纹或面部识别等生物识别验证）。MFA 系统的设计旨在防御 SFA 系统无法防范的特定漏洞，例如网络钓鱼攻击或密码泄露。在 MFA 系统中使用通行密钥时，它们通常被用作独立的 MFA 选项。在这些情况下，至关重要的是，任何回退或恢复方法都要保持与通行密钥同等的安全级别。

2.3 回退和恢复#

回退用于所有多种身份验证方法并存的系统。当主要方法不可用时就会使用它们——用户在注册开始时通常可以选择（例如社交登录与密码）。回退可能涉及替代身份验证策略，例如通过电子邮件的 OTP、密码、包含匹配电子邮件的社交登录、原生应用推送、QR 码或安全密钥。这些回退方法中的每一种在安全质量上都有所不同，选择适当的回退选项对于平衡用户便利性与安全要求至关重要。

在将通行密钥作为多因素身份验证 (MFA) 系统的一部分的环境中，必须仔细考虑这些回退方法，以确保它们提供与通行密钥相媲美的多因素安全性。当用户失去对符合所需安全标准 (SFA 或 MFA) 的所有既定身份验证措施的访问权限时，恢复流程就变得非常重要。这在单因素系统中不太关键，在单因素系统中可能有多个恢复选项可用，例如通过电子邮件 OTP 重置密码，这有效地验证了用户对相关标识符的控制。然而，在 2FA/MFA 系统中恢复尤其具有挑战性，因为这些系统本身依赖多个因素进行验证。在用户切换移动操作系统（例如从 iPhone 切换到 Android 手机）并丢失相关通行密钥和电话号码的情况下，剩余因素（例如，仅密码）无法满足 2FA 要求。在这些情况下的恢复可能需要创建新的身份证明，这可能涉及手动支持请求或我们稍后将讨论的更具创新性的解决方案。

3. 通行密钥登录回退：手动通行密钥登录与自动通行密钥登录#

在实施通行密钥解决方案时，首先要做的决定之一是通行密钥登录的策略。根据用例的不同，手动登录对于较小的平台可能就足够了，但对于较大的面向用户体验的公司，推荐使用标识符优先策略，在输入主要标识符（极有可能是电子邮件）后提供通行密钥登录。

3.1 手动通行密钥登录：用户主导策略#

3.1.1 什么是用户主导策略？#

在较小平台或不关注高通行密钥登录率的平台上，用户主导策略涉及单独的“使用通行密钥登录”按钮。在这种策略中，使用通行密钥的责任完全落在了用户身上。在将通行密钥添加到帐户后，用户必须记住点击“使用通行密钥登录”来使用它进行登录。

该屏幕截图显示了 https://my.gov.au 的通行密钥实施情况，它使用了手动通行密钥登录方法。虽然这种方法更容易实施，因为后端不需要确定是否可以进行通行密钥登录，但它通常会导致通行密钥登录率大打折扣。这是因为该方法严重依赖用户的自主性，而且消费者可能记不住或不确定他们的通行密钥位于哪个平台或云存储上。这种方法会迫使让用户思考。让我们在下一节中看看这种方法可能存在哪些回退机会。

3.1.2 回退选项#

在任何通行密钥可能访问失败的系统中，回退选项都是必不可少的。在手动通行密钥登录方法中，无法单独管理对话框和回退操作，因为所有登录选项都在同一时间显示，而通行密钥是由用户自行决定的。这导致了几个挑战：

• 不直观的错误： 当通行密钥不可用或设置不正确时，用户遇到的错误消息通常不明确并会引起混乱。用户可能不明白为什么他们无法使用通行密钥或出了什么问题，从而产生挫败感。
• 死胡同： 用户可能会发现自己陷入了无法继续前行的死胡同。如果缺少或无法访问通行密钥，用户可能无法获得关于如何继续或恢复访问的任何明确指导，导致他们放弃登录过程。
• 缺乏引导： 在这些情况下，系统无法提供有用的说明来引导用户选择替代的身份验证方法。用户只能自己弄清楚如何解决问题，这降低了用户体验。

上面的例子显示了当在平台身份验证器上找不到通行密钥时，Windows 11 的错误消息有多么令人困惑。系统可能会假定通行密钥驻留在安全密钥或其他设备上。这个过程可能会使不熟悉此类身份验证流程的用户感到困惑，特别是如果他们以前从未用过安全密钥或从未创建过通行密钥。

**如果在平台身份验证器上未找到通行密钥，操作系统和浏览器会假定它们一定存在于其他地方，如果用户尚未创建过通行密钥，这将导致进一步的困惑。**条件 UI 可以通过显示现有的通行密钥来提供帮助，但这只有在通行密钥实际存在时才有效。为了获得最佳的通行密钥体验，后端应在用户提供其主要标识符后决定是否应触发通行密钥登录。

3.2 自动通行密钥登录：标识符优先策略#

3.2.1 什么是标识符优先策略？#

在标识符优先策略中，系统会要求用户在确定是否可以进行通行密钥登录之前，先提供其主要标识符，例如电子邮件或电话号码。**验证标识符后，系统会自动建议最合适的登录方法，包括通行密钥（如果可用且可访问）。**这种方法更加用户友好，因为它消除了用户需要记住选择“使用通行密钥登录”选项的需求，并通过简化流程提高了采用率。

Google 标识符优先登录

Google 通行密钥登录

上述屏幕截图显示了在 macOS 设备上关联了通行密钥的帐户的 Google 登录行为。 Google 也遵循标识符优先策略，并判断出极有可能进行通行密钥登录：

1. 平台对通行密钥的支持： 底层平台支持平台身份验证器，因此可以登录。
2. 通行密钥可访问： 通行密钥很可能可以在此客户端 (macOS) 上访问，因为它是在 macOS 系统上创建的。

因此，系统会自动启动通行密钥登录，引导用户获得最佳体验。这遵循了“不要让我思考”的策略。

3.2.2 缺少通行密钥平台支持或通行密钥可访问性#

系统确定是否可以进行通行密钥登录。如果是以下情况：

• 通行密钥不存在： 用户尚未为其帐户创建通行密钥
• 通行密钥不可访问： 用户创建的通行密钥极有可能在此客户端上不可用（例如，用户只有 macOS 通行密钥，而现在从 Windows 登录）。
• 不支持通行密钥身份验证： 当前客户端不支持平台身份验证器，并且也很可能不支持通过 QR 码的跨设备身份验证

系统将判定不太可能成功进行通行密钥登录，**因此会自动提供回退选项，而不会触发通行密钥登录。**这种方法更加用户友好，因为它消除了用户需要记住选择“使用通行密钥登录”选项的需求，通过简化流程提高了采用率，并避免了向用户显示令人困惑的死胡同这一最坏情况。

在上面的示例中，登录回退到密码，然后将继续根据帐户的状态和安全性要求提供进一步的身份验证因素，因为客户端是 Windows 11 设备，它不太可能有权访问 macOS 通行密钥。根据身份验证系统的安全要求，你可以完全控制在这种情况下触发哪种身份验证方法（例如，最后一次成功的非通行密钥身份验证选项）。

3.2.3 通行密钥流程中止#

当用户在网络登录期间遇到身份验证屏幕时，他们可能会感到惊讶或不知所措，特别是如果这是他们第一次使用基于通行密钥的身份验证。这可能导致用户中止身份验证过程，这不是由于失败，而仅仅是因为他们不确定发生了什么。规划这种行为并将首次中止视为正常事件而不是错误至关重要：

首次中止屏幕应以平静和令人安心的方式清楚地解释发生了什么，并建议用户重试该过程（请参阅上方的 Google 示例）。该屏幕的设计旨在最大程度地减少焦虑，将中止视为用户体验中常规且预期的一部分。许多用户中止仅仅是因为他们不认识身份验证屏幕或不熟悉该过程。因此，重试应该是默认建议。

然而，如果发生第二次中止，情况应区别对待。第二次中止可能表明确实出了问题——无论是平台身份验证器的问题，还是用户找不到合适的通行密钥，抑或是 WebAuthn 流程中的技术故障。此时，系统应呈现一个不同的屏幕，说明出现了问题，并更多地建议回退选项：

**第二次中止屏幕应鼓励用户切换到替代身份验证方法。**它应该确保用户仍然可以成功登录，而不会引起进一步的挫败感。从上方的屏幕我们可以看到，Google 仍然建议“重试”，但同时也向用户显示可能出了问题。

3.3 通行密钥实施策略比较#

下表通过总结最重要的特征，帮助比较不同的策略：

自助构建的策略通常遵循手动通行密钥登录策略，并依赖于条件 UI 且需用户选择加入通行密钥，这导致通行密钥登录率非常低并让用户感到沮丧。标识符优先策略需要在条件 UI 之上建立周密考虑的设备逻辑，这正是 Corbado 可以为您提供帮助的地方。不建议构建您自己的设备逻辑和通行密钥智能分析，因为该规则集需要不断微调和调整以适应新设备、新的 WebAuthn 和云同步功能（例如 GPM 通行密钥）。

4. 通行密钥恢复#

当用户失去对其通行密钥的访问权限时，通行密钥恢复是维护安全性和用户体验的一个至关重要的方面。 这在依赖 MFA 的系统中尤为重要。在 MFA 情况下，恢复流程必须确保在允许用户重新获得对其帐户访问权限的同时维护安全性。必须根据系统中使用的身份验证级别定制恢复策略。

4.1 单因素恢复和多因素恢复#

为了维护 SFA 系统的安全性，恢复通常涉及证明对标识符（例如电子邮件地址或手机号码）的控制权。

• 电子邮件 OTP： 将 OTP 发送到用户注册的电子邮件地址。验证后，用户可以重新获得访问权限并创建新的通行密钥。
• 短信 OTP： 与电子邮件恢复类似，将 OTP 发送到注册的手机号码。用户可以使用此 OTP 重新获得对其帐户的访问权限。

虽然这些方法很简单，但它们依赖于保持用户联系信息的最新状态。因此，必须在常规登录期间定期提示用户验证其电子邮件和电话号码。

在多因素身份验证系统中，恢复变得更加复杂。由于 MFA 依赖于多个独立的因素（例如通行密钥、社交登录和 OTP），用户不应仅仅因为一个因素（例如通行密钥）不可用而失去访问权限。

• 使用备用因素： 如果通行密钥丢失，用户可以使用其他两个因素进行身份验证，例如密码加短信 OTP 或身份验证器应用程序。一旦他们通过身份验证，他们就可以创建一个新的通行密钥。
• 使用其他通行密钥： 如果用户还有带有通行密钥的其他设备，他们可以借助适当的提示使用这些设备来重新获得访问权限（例如，请求使用 iPhone 上的通行密钥）。
• 创建新通行密钥： 使用恢复方法通过身份验证后，应引导用户创建一个新的通行密钥，以确保 MFA 设置保持完整。

对于 SFA 和 MFA 系统来说，关键是确保恢复过程健壮安全，同时尽量减少用户的摩擦。

4.2 智能 MFA 恢复：数字化 MFA 恢复成本#

在处理敏感个人数据、受监管行业或政府部门服务的系统中，标准电子邮件 OTP 和手机号码 OTP 可能并不总是足以进行恢复或可用。在这种情况下，智能 MFA 恢复机制提供了高级的帐户恢复方法，可以在保持高安全标准的同时，为用户提供无缝的体验。

最有效的方法之一是带有活体检测的自拍识别。此过程要求用户拍摄其身份证件的照片。此外，自拍活体检测确保自拍是实时拍摄的，确认用户在场并与拍摄的身份证相符，从而防止使用静态图像或被盗的身份证进行欺诈。根据所使用的技术，活体检测可以通过录制一段改变与摄像头距离的短视频，或者头部旋转 180 度来完成（例如 Apple Face ID）。

当传统的恢复方法（如电子邮件或短信 OTP）不可用或已过时，这种方法也特别有用。例如，以下是一个拍摄自拍的示例，然后是 Onfido 的活体检测：

示例：Onfido 的具有活体检测的自拍身份识别

• 政府系统、受监管行业或大型商业服务通常拥有可用于验证身份证件上可用信息的个人数据。如果例如出生日期不可用，通过身份证收集的信息可以用作手动恢复过程中的因素。

此外，其他智能恢复方法可以包括：

• 跨设备恢复： 如果用户有受信任的辅助设备，他们可以通过扫描 QR 码来恢复帐户。
• 已知环境： 如果用户仍然可以访问他们过去成功使用的同一台设备，他们可以使用该设备并因此提供额外保证因素的证明，表明他们在从同一个设备、提供商和位置操作，以帮助手动恢复过程。Google 在其 Gmail 账户恢复 中使用了这种方法。
• 数字凭证 API (Digital Credentials API)： 随着数字身份钱包的日益普及，预计通过此 API 直接验证将在安全且用户友好的帐户恢复中发挥越来越重要的作用。

智能 MFA 恢复方法旨在为用户提供安全、直观的方法来重新获得对其帐户的访问权限，特别是在处理高度敏感或受监管的信息时。这些方法确保即使用户无法使用电子邮件或电话恢复等传统方法，也可以安全有效地恢复访问。智能恢复有助于降低 MFA 恢复的成本。

4.3 MFA 恢复频率：电话号码与通行密钥#

需要记住的一点是，因为通行密钥在云中同步，所以 36 个月内的 MFA 恢复成本要低得多，因为更改手机号码的频率远远高于从 Apple 切换到 Android（或反之亦然）。在手机或电话合同发生变更的情况下，通行密钥将会被恢复。

因此，失去对同步通行密钥的访问权限的频率将远低于失去对手机号码的访问权限，而失去对手机号码的访问权限会导致传统的面向消费者的 MFA 系统的大部分恢复痛点。

尽管如此，随着用户群的增长，此类情况仍然会造成大量的人工支持成本，应使用数字化解决方案进行处理，我们将在下一节中探讨。

5. 给产品经理和开发人员的建议#

在将通行密钥集成到身份验证系统中时，至关重要的是仔细规划回退选项和恢复策略，以保持高水平的安全性并确保无缝的用户体验。为了最大化通行密钥登录的使用率，请考虑以下建议：

• 选择标识符优先策略： 这种策略更加用户友好，并减少了登录过程中的摩擦。通过要求用户首先输入其主要标识符（例如，电子邮件或电话号码），系统可以自动确定是否可以进行通行密钥登录。这可确保流畅直观的登录体验，而无需依赖用户手动选择通行密钥选项。
• 使用具有解释性的中止屏幕以获得更好的用户体验： 尽管安全应作为首要任务，但设计一个帮助用户采用通行密钥的流程也同样重要。确保第一次的流程中止被视为常态，并给出清晰的重试指导。
• 保持回退和恢复选项的安全性： 确保回退方法（例如电子邮件 OTP 和/或短信 OTP）的安全性与主要身份验证方法相匹配。例如，在使用通行密钥的 MFA 系统中，回退也应该要求多个因素，以保持相同的安全标准。
• 自动执行定期的恢复提示： 在登录期间定期提示用户验证其联系信息（电子邮件地址或电话号码），以确保当他们使用通行密钥时恢复选项保持最新状态。这减少了用户因恢复方法过时而被锁定在帐户之外的几率。
• 考虑使用智能恢复方法以增强安全性并降低支持恢复成本： 对于受监管行业或拥有访问个人数据以进行在线身份检查的系统，请考虑诸如具有活体检测的自拍识别等高级恢复方法。根据你的安全要求，此方法可以提供额外的安全层，同时保持恢复过程直观且用户友好。

最大化通行密钥的登录率取决于你实现这些元素的出色程度。确保顺畅的回退和恢复选项将使用户对使用通行密钥作为主要身份验证方法充满信心。

6. Corbado 能为你做些什么：UI 组件和通行密钥智能分析#

Corbado 提供了实施标识符优先策略所需的一切，无论是需要完整的新身份验证系统的全新项目，还是需要将通行密钥添加到现有身份验证系统的现有项目。

6.1 适用于不同用例的 UI 组件#

这两款产品均提供可根据你的需求定制的 UI 组件：

1. Corbado Complete：以通行密钥优先的身份验证开启你的项目
   这是我们完整的身份验证系统，其中包含无缝的标识符优先策略，旨在简化登录流程。Corbado Complete 通过在用户提供其标识符后自动判定是否可以进行通行密钥登录，实现了既安全又人性化的体验。这减少了阻力并确保了顺畅的登录体验，这对于实现通行密钥普及至关重要。
2. Corbado Connect：无需迁移到任何应用程序即可添加通行密钥
   对于已经建立身份验证流程且希望将通行密钥作为增强功能的业务而言，Corbado Connect 为单因素和多因素策略提供了附加解决方案。通过将通行密钥无缝集成为既安全又便捷的选项，此策略能够作为对你现有基础设施的有力补充，让用户能够在无需彻底改变当前系统的情况下通过通行密钥进行身份验证。例如，Corbado Connect 可以无缝嵌入到 Amazon Cognito 中。

我们严格将我们的方法与 Google 等行业领导者以及大型科技领域的其他知名参与者保持一致，专门针对面向消费者的公司量身定制。

6.2 通行密钥智能分析支持标识符优先策略#

我们的目标不仅是最大化通行密钥的采用率（即创建通行密钥），还要确保这些通行密钥被积极使用，以实现高登录率（从而提高安全性并降低短信 OTP 成本）。我们的 UI 组件在构建时充分考虑了标识符优先策略，并直接连接到我们的通行密钥智能分析，它会根据客户端环境和现有通行密钥来决定通行密钥的可用性和可访问性。它们支持所有讨论的回退和恢复功能。以下屏幕显示了我们的中止和重试逻辑：

通行密钥首次中止

通行密钥第二次中止

通过同时关注通行密钥的采用率和使用情况，我们能够帮助你在安全性和用户体验之间取得平衡，确保用户可以继续以无摩擦的方式使用通行密钥。

7. 结论#

在本指南中，我们探讨了将通行密钥集成到身份验证系统后各种可能的回退和恢复策略。我们在整篇文章中解答了引言中提出的关键问题：

• 存在哪些回退方案？ 可能会出现几种回退情况，例如缺少对通行密钥的支持或在特定设备上无法访问通行密钥。为了维持安全性并提供流畅的用户体验 (UX)，当无法使用通行密钥登录时，应该提供诸如电子邮件或短信 OTP 这样的回退选项。
• 应该如何处理恢复？ 恢复流程的设计应匹配身份验证系统的安全级别。在 SFA 系统中，电子邮件或短信 OTP 就足够了；而在 MFA 系统中，必须使用其他因素来重新获得访问权限并创建新通行密钥。在监管严格或敏感度高的环境中，诸如带有活体检测的自拍识别之类的智能恢复方法可提供更高的安全性。

通过遵循本指南中概述的最佳实践，产品经理和开发人员能够设计出稳健的基于通行密钥的身份验证系统，为用户提供安全且无缝的登录体验。安全性不应该以牺牲用户体验为代价，通过周密的设计和规划是可以同时实现两者的。

关于 Corbado

Corbado 是面向大规模运行 consumer 身份验证的 CIAM 团队的Passkey Intelligence Platform。我们让你看到 IDP 日志和通用 analytics 工具看不到的内容：哪些设备、操作系统版本、浏览器和 credential manager 支持 passkey，为什么注册没有转化为登录，WebAuthn 流程在哪里失败，以及什么时候操作系统或浏览器更新会悄悄破坏登录 — 而且无需替换 Okta、Auth0、Ping、Cognito 或你自有的 IDP。两款产品：Corbado Observe 提供 针对 passkey 及任何其他登录方式的 observability。Corbado Connect 提供 内置 analytics 的 managed passkey（与你的 IDP 并存）。VicRoads 通过 Corbado 为 500 万以上用户运行 passkey（passkey 激活率 +80%）。 与 Passkey 专家交谈 →

常见问题解答#

标识符优先策略如何处理当前设备上无法访问通行密钥时的登录？#

当通行密钥可能无法访问时（例如从 Windows 设备访问 macOS 的通行密钥），系统会自动跳过通行密钥提示，并提供密码或 OTP 等回退选项。这遵循了“不要让我思考”的策略，仅在很可能成功的情况下才触发通行密钥登录，从而避免了令人困惑的死胡同。

当用户在中间流程中止通行密钥身份验证时应该发生什么？#

首次中止应被视为正常事件，屏幕上应平静地鼓励用户重试，因为许多用户中止只是因为他们对身份验证屏幕不熟悉。如果发生第二次中止，系统应该显示回退身份验证选项，因为这可能表明平台身份验证器或通行密钥的可用性存在真正的问题。

当用户失去对其通行密钥的访问权限时，MFA 系统有哪些恢复选项？#

在 MFA 系统中，用户可以通过使用两个备用因素（例如密码加短信 OTP）进行身份验证，或通过从其他受信任设备使用通行密钥，然后创建新通行密钥来进行恢复。对于无法使用传统恢复方法的受监管行业，具有活体检测的自拍识别等智能方法提供了额外的安全恢复路径。

为什么与标识符优先策略相比，手动“使用通行密钥登录”按钮方法会导致采用率较低？#

手动方法将完全的责任交给了用户，要求他们自己记住并选择通行密钥选项，这通常会导致通行密钥登录率大大降低。当在平台身份验证器上找不到通行密钥时，用户还可能会遇到不明确的错误消息，从而导致挫败感并放弃登录尝试。