WebAuthn 通行密钥二维码与蓝牙：混合传输

通行密钥正越来越多地取代密码，成为用户身份验证的事实标准。与传统密码不同，通行密钥与一个生态系统绑定（例如 iCloud 钥匙串、Google 密码管理器、Windows Hello 或像 1Password 或 Dashlane 这样的密码管理器）；它们不是为记忆而设计的，而是为了与您的设备无缝集成，提供卓越的开箱即用用户体验。

想象一下，您不在个人电脑旁，可能在公共终端或朋友的笔记本电脑上，需要登录您受通行密钥保护的账户。这种情况相当普遍，需要一种安全又便捷的身份验证方法，但对于通行密钥，许多人不知道该怎么做，因为在这种情况下他们的通行密钥并非立即可用。在这种情况下，通行密钥的一项功能可以帮助您，即通过二维码和蓝牙技术在多个设备上使用您的通行密钥。这个过程在 WebAuthn 规范中被正式称为混合传输（在规范的早期版本中，它被称为云辅助低功耗蓝牙 caBLE）。

这个过程很简单：您需要一个存储了您的通行密钥并且能够拍照的设备，所以很可能是一部智能手机或平板电脑。该设备可以为这一次身份验证实例与新设备建立一个通道。这不仅维护了您通行密钥的完整性，还确保了无论您身在何处或想使用谁的设备登录，都可以授予对您在新设备上账户的访问权限。

然而，这项通行密钥跨平台身份验证功能在其效用和技术实现上都存在误解和困惑。这是我最近在参加一个本地 IT 安全聚会时再次注意到的。通过本文，我们旨在揭示其复杂性，并为实现这种跨平台通行密钥身份验证（混合传输）流程提供建议，确保您能为用户提供最佳的登录体验。

通行密钥是一种用户身份验证形式，它用更安全、更便捷的加密公私钥对取代了传统密码。这对密钥对每个用户都是唯一的，用于验证身份，而无需记住复杂密码的麻烦。

与密码前辈相比，通行密钥的优势是多方面的。它们显著降低了网络钓鱼的风险，因为它们不会被诱骗与虚假网站共享。此外，它们对暴力破解和字典攻击免疫，这些是破解密码的常用方法。通行密钥也更加用户友好，消除了记住或管理一长串密码的需要。

通行密钥在云账户中同步，例如由 Google 密码管理器或 Apple iCloud 钥匙串管理的账户（微软的 Windows Hello 也将很快跟进），或者存储在支持通行密钥的现代密码管理器中，如 1Password 或 Dashlane。然而，必须知道，默认情况下，通行密钥是与生态系统和相应的云账户同步绑定的。操作系统不提供导出私钥的接口，在大多数设备中，都有一个硬件组件提供额外的安全措施以防止任何对私钥的访问，例如 iOS 设备上的安全隔区或 Windows 设备上的可信平台模块 (TPM)。只有操作系统提供商才能以加密方式将通行密钥同步到其他设备（最终由用户的生物识别、密码或 PIN 码保护）。私钥只能使用密码/PIN 码恢复和解密，如果对云账户的登录尝试失败次数过多，私钥将被销毁（例如，Apple 引入了速率限制以防止即使在云后端具有特权位置的暴力破解攻击；Google 也是如此）。

这种固有的设计意味着，如果通行密钥没有如上所述同步，在新设备上访问您的通行密钥可能会带来挑战。这正是为什么存在使用二维码和蓝牙邻近性检查的通行密钥跨平台身份验证（混合传输）方法。它为您的通行密钥在设备之间提供了一个安全的桥梁，而无需通过云账户/密码管理器进行同步，从而维护了通行密钥可以完全由用户保管的原则。

当账户纯粹通过通行密钥访问时，使用混合传输的跨平台通行密钥身份验证有助于克服跨设备问题。由于并非所有通行密钥都在云账户或密码管理器中同步，因此在设备间访问通行密钥的可靠方法变得至关重要，尤其是在过渡到新设备或需要在共享设备上访问时。

为了实现通行密钥跨平台身份验证（混合传输），有以下硬件要求：

• WebAuthn 支持： 设备必须支持 WebAuthn。根据我们最新的通行密钥数据分析，99% 的设备已经具备此功能。
• 用于扫描二维码的摄像头： 设备需要一个能够扫描二维码的摄像头。大多数现代智能手机都配备了具有此功能的摄像头。此外，摄像头需要内置二维码扫描功能（大多数设备开箱即用）。如果您的摄像头不支持，那么在线二维码扫描器也是一个不错的选择。否则，安装一个二维码应用也可以。
• 蓝牙功能： 云辅助低功耗蓝牙（caBLE）用于在设备之间建立基于邻近性的安全连接。需要寻找的版本是蓝牙 4.0 或更高版本，这些版本支持 WebAuthn 的 caBLE 扩展。
• 互联网连接： 两台设备上都需要有稳定的互联网连接，因为交换过程涉及打开一个隧道以执行需要实时数据传输的验证步骤。

从软件角度来看，存在以下要求：

• WebAuthn 服务器配置： 显然，您需要有一个管理公钥的 WebAuthn 服务器。这还包括使用户账户能够与多个验证器链接，并设置服务器以启动身份验证仪式。
• Web Bluetooth API： 对于蓝牙邻近性检查，您需要访问 Web Bluetooth API，该 API 从浏览器触发设备的蓝牙功能。
• 操作系统要求： 请参阅以下关于截至 2025 年 3 月不同操作系统对跨设备身份验证支持的表格。验证器意味着该设备可以作为持有通行密钥的设备（在我们的场景中是智能手机）。客户端是指创建二维码并且用户尝试登录的设备（在我们的场景中是台式机）：

来源：passkeys.dev

通过二维码使用通行密钥跨平台身份验证（混合传输）的过程如下：

当用户尝试在没有注册通行密钥的设备上访问服务，但服务知道该用户应该有通行密钥时，会生成用于通行密钥跨平台身份验证（混合传输）的二维码。通常，在身份验证界面中会提供一个“扫描二维码”按钮或类似的操作号召。

根据用户请求，设备启动二维码的生成。此二维码编码了一个唯一的、有时间限制的会话标识符。此标识符与身份验证服务器临时维护的会话相关联，等待身份验证过程完成。

用户使用存有其通行密钥的设备扫描此二维码。安全措施包括：

• 一次性使用： 二维码中的会话标识符仅限单次使用，以防止重放攻击。
• 加密： 二维码内的所有数据都经过加密，确保任何被截获的通信都无法被未经授权的方破译。

扫描的二维码包含一个特定的 URI，其方案为 FIDO，例如： FIDO:/07824133892604070278923969472008301099476228966286113051476699183587 6383562063181103169246410435938367110394959927031730060360967994421 343201235185697538107096654083332

扫描二维码会触发用户的第二台设备（例如智能手机或平板电脑）解释 FIDO URI 并与身份验证服务器通信，发送一个信号表明用户正试图通过新设备（例如朋友的笔记本电脑）进行身份验证。此操作会提示服务器生成一个对此身份验证尝试唯一的加密挑战。

挑战被发送回用户的第二台设备（例如智能手机或平板电脑），那里存储着他们的通行密钥。然后，设备使用与通行密钥关联的私钥创建数字签名，而私钥永远不会离开设备（例如智能手机或平板电脑）。签名的挑战（签名）然后通过一个安全的、加密的互联网隧道发送回服务器，验证身份验证尝试的完整性和来源。

服务器使用已与用户账户关联的相应公钥验证签名。验证成功后，服务器确认身份验证，允许用户在新设备上访问服务。

一些更重要的隐私和安全方面需要考虑：

• 无蓝牙数据交换，纯互联网： 重要的是要注意，在这种基于二维码的通行密钥跨平台身份验证（混合传输）中，蓝牙不参与数据交换。此过程完全依赖于互联网连接来在设备和服务器之间传输加密数据。然而，蓝牙用于两台设备的邻近性检查。
• 私钥不离开设备： 在整个过程中，用户的私钥安全地保留在他们的设备上。
• 无敏感数据暴露： 在身份验证过程中，不会传输或暴露任何敏感的通行密钥信息或私钥。
• 非对称加密： 质询-响应机制确保发送的仅仅是不可重用的、已签名的挑战版本，这些版本不能被用于未经授权的访问。

通过遵守这些技术和安全协议，用于通行密钥跨平台身份验证（混合传输）的二维码方法在提供用户在新设备上验证身份的便捷方式的同时，保持了高标准的安全。

除了二维码扫描过程，还有通过蓝牙 (caBLE) 进行的邻近性检查。确保客户端和验证器物理上彼此靠近是 WebAuthn 协议的主要好处之一。以下将更深入地描述此过程的内部工作原理：

低功耗蓝牙 (BLE) 是一种专为短距离数据交换设计的无线通信技术。它在身份验证过程中确认设备的物理邻近性方面起着关键作用。

caBLE 是一种协议，它利用 BLE 在设备之间安全地传输身份验证信息。当使用 caBLE 进行通行密钥跨平台身份验证（混合传输）时，持有通行密钥的设备通过 BLE 信号确认请求设备的邻近性。一旦邻近性得到验证，身份验证过程就会继续，利用 BLE 进行安全的本地通信。

用户体验得到增强，因为这种方法通常需要较少的直接用户交互；物理上靠近的设备会自动相互检测。在安全性方面，caBLE 提供了一个显著的优势——它确保身份验证过程仅在两台设备彼此靠近时进行，从而防止远程攻击者发起身份验证过程。

想象一下收到一个重定向到恶意网站的二维码。如果通过此二维码进行身份验证，会话或 cookie 就有被劫持的风险。BLE 通过不依赖视觉扫描，而是依赖设备的物理存在来规避此问题。这种邻近性检查最大限度地降低了中间人攻击的风险，因为邻近性检查不是通过互联网或视觉媒介进行的。

与其他方法不同，caBLE 实际上不交换像通行密钥这样的身份验证数据。相反，它使用 BLE 作为一个确认通道，以确定设备在物理上是靠近的。此检查旨在成为多因素身份验证过程的一部分，其中 BLE 邻近性是因素之一，确保即使其他因素被泄露，没有物理邻近性也无法授予访问权限。

通过集成 caBLE 协议，开发人员可以为通行密钥跨平台身份验证（混合传输）提供一种安全且用户友好的方法，从而增强身份验证过程的整体安全性。邻近性检查增加了一个额外的保护层，对用户来说很简单，但能有效防范某些类型的复杂网络攻击。

这种通行密钥跨平台身份验证（混合传输）方法具有以下优点：

通过二维码和蓝牙（混合传输）进行跨平台通行密钥身份验证是在跨平台场景中改善用户体验的一种方式，相比于完全不提供任何可能性。然而，这个用户流程对大多数用户来说是全新的，我们不期望很多非技术用户在第一次遇到这个流程时就能理解发生了什么。引入二维码流程的唯一相似之处可能是 WhatsApp Web 或 Discord 的登录流程，它们也使用二维码（尽管功能不同）。因此，所分析的通过二维码/蓝牙（混合传输）的跨平台通行密钥身份验证过程在跨平台场景中最大限度地减少了用户的工作量，因为无需手动输入任何凭据，但整体流程对大多数用户来说仍然是未知的。

通行密钥跨平台身份验证（混合传输）的安全性通过先进的加密技术得到加强。当为身份验证扫描二维码或建立蓝牙连接时，加密的质询和响应确保只有预期的设备才能成功完成身份验证过程。

通过蓝牙进行的邻近性检查增加了一个额外的安全层，确认身份验证尝试是由具有对辅助设备的物理访问权限的人进行的。

在跨平台身份验证（混合传输）过程中，通行密钥绝不会临时存储在中间设备或服务器上，这防止了通行密钥在传输过程中被拦截或泄露的风险。身份验证是实时发生的，通行密钥仍然与其用户的主设备绑定，保持其完整性。

二维码和蓝牙身份验证方法固有地提供了对网络钓鱼的保护。用户不太可能被诱骗为恶意网站提供通行密钥，因为身份验证过程需要特定于用户可信设备的物理操作。

扫描二维码或通过蓝牙连接的过程通常在受信任的环境中进行，减少了用户无意中泄露其凭据的机会。

这种通行密钥跨平台身份验证（混合传输）方法存在以下缺点：

引入任何新技术都可能导致用户困惑，特别是如果用户不精通技术。通过二维码和蓝牙（混合传输）进行通行密钥跨平台身份验证是对传统身份验证方法的重大转变，一些用户可能会觉得新过程难以掌握，可能导致采用率较慢。然而，我们预计用户最终会习惯它，所以开始时变化可能更困难，但随着时间的推移会变得更平滑、更容易被接受。

通行密钥跨平台身份验证（混合传输）的成功在很大程度上依赖于用户的设备是否具备必要的能力，例如可以扫描二维码的摄像头和蓝牙功能。使用缺乏这些功能的旧设备的用户将无法利用通行密钥跨平台身份验证（混合传输），从而造成基于硬件限制的数字鸿沟。

用户行为可能不可预测，依赖用户执行特定操作（如扫描二维码或启用蓝牙）可能会引入用户错误。例如，由于配对问题、发现问题以及用户普遍对无线技术用于安全交易的不信任，蓝牙有时可能被视为用户体验的挑战。

开发者面临着不断更新和维护系统以支持最新身份验证方法的任务。将通行密钥跨平台身份验证（混合传输）集成到现有系统中，要求开发者紧跟新标准、采用新 API 并确保向后兼容，这可能是资源密集型和耗时的。

对于每个新设备或后续的登录请求，如果不使用像 iCloud 钥匙串或密码管理器这样的同步云账户，就需要创建一个新的通行密钥。这可能会增加用户体验的复杂性，如果用户不熟悉该过程或过程不够直观，可能会产生挫败感。

在实施像通行密钥跨平台身份验证（混合传输）这样的新安全方法时，存在对用户进行教育的内在需求。确保用户了解如何安全地使用二维码和蓝牙需要清晰的沟通，并可能需要广泛的客户支持。

虽然通过二维码和蓝牙（混合传输）进行通行密钥跨平台身份验证代表了身份验证技术的重大进步，但这些潜在的缺点凸显了对用户友好设计、强大的支持系统以及从传统方法到创新方法的渐进、沟通良好的过渡的需求。与任何技术转变一样，平衡创新的好处与其挑战将是成功实施和广泛用户接受的关键。

作为免责声明：在以下测试中，我们忽略了硬件安全密钥（例如 YubiKeys），只使用内置于设备中的平台验证器（例如 Face ID、Touch ID、Windows Hello）。在使用硬件安全密钥（例如 YubiKey）的情况下，transports 的值将是 usb 或 nfc。

我们使用以下设备/浏览器组合和 Passkeys Debugger 来测试行为。Android 不在考虑之列，因为 Android 不能作为跨平台身份验证（混合传输）客户端（参见上文的表格）：

为了测试行为，我们为每个组合创建一个具有以下属性的新通行密钥：

• userName: alex muller（在此测试中无影响）
• authenticatorAttachment: platform（因为我们想排除像 YubiKeys 这样的硬件安全密钥）
• residentKey: preferred（在此测试中无影响）
• userVerification: preferred（在此测试中无影响）
• attestation: none（在此测试中无影响）
• hints: empty（见下文解释）
• usePRF: no（在此测试中无影响）

成功创建通行密钥后，我们然后修改 allowCredentials WebAuthn 服务器属性的输入并发起登录请求。我们想模拟在我们创建通行密钥的设备上删除了通行密钥的情况，以便设备/浏览器寻找另一台可以通过二维码/蓝牙提供通行密钥的设备。因此，我们更改凭据 ID 并分配值 CHANGED-ID，以便匹配失败。此外，我们更改 allowCredentials 中 WebAuthn 凭据的 transports 属性，并为每个设备/浏览器组合分配以下值：

1. transports: [internal, hybrid]: 通行密钥可以从平台验证器（例如 Face ID、Touch ID、Windows Hello）或通过跨平台身份验证使用
2. transports: [internal]: 通行密钥可以从平台验证器（例如 Face ID、Touch ID、Windows Hello）使用
3. 未设置 transports 属性： 默认行为，不设限制

在 WebAuthn 测试网站中，还提供了新的 WebAuthn Level 3 功能，用于用户代理提示。如果信赖方对如何以最用户友好的方式完成登录请求有某些假设，此功能可以改善用户体验。在此测试中，我们忽略了此功能，因为它尚未推出。请参阅规范以获取更多详细信息。

正如预期的那样，没有匹配的本地通行密钥，因此建议扫描二维码并在另一台设备上使用通行密钥（因为系统知道该用户存在通行密钥）。

令人困惑的是，即使我们只允许内部凭据，这里也显示了二维码。我们找不到这种行为的合理解释。

没有匹配的本地通行密钥，因此建议扫描二维码或使用硬件安全密钥（例如 YubiKey）/跨平台验证器/漫游验证器。

出于某种原因，模态框的部分内容以德语显示，这是已安装的语言之一。

正如预期的那样，所有形式的通行密钥身份验证都是允许的：通过 Windows Hello、通过二维码、通过已知设备和通过硬件安全密钥。

正如预期的那样，没有匹配的本地通行密钥，因此建议扫描二维码并在另一台设备上使用通行密钥（因为系统知道该用户存在通行密钥）。

令人困惑的是，即使我们只允许内部凭据，这里也显示了二维码。我们找不到这种行为的合理解释。

没有匹配的本地通行密钥，因此建议扫描二维码或使用硬件安全密钥（例如 YubiKey）/跨平台验证器/漫游验证器。

出于某种原因，模态框的部分内容以德语显示，这是已安装的语言之一。

正如预期的那样，所有形式的通行密钥身份验证都是允许的：通过 Windows Hello、通过二维码、通过已知设备和通过硬件安全密钥。

创建通行密钥时，我们收到了以下错误（但仍然创建了通行密钥）：

error: TypeError: 'toJSON' called on an object that does not implement interface PublicKeyCredential.

正如预期的那样，没有匹配的本地通行密钥，因此建议扫描二维码并在另一台设备上使用通行密钥（因为系统知道该用户存在通行密钥）。

令人困惑的是，即使我们只允许内部凭据，这里也显示了二维码。我们找不到这种行为的合理解释。

没有匹配的本地通行密钥，因此建议扫描二维码或使用硬件安全密钥（例如 YubiKey）/跨平台验证器/漫游验证器。

出于某种原因，模态框的部分内容以德语显示，这是已安装的语言之一。

正如预期的那样，所有形式的通行密钥身份验证都是允许的：通过 Windows Hello、通过二维码、通过已知设备和通过硬件安全密钥。

正如预期的那样，没有匹配的本地通行密钥，因此建议扫描二维码并在另一台设备上使用通行密钥（因为系统知道该用户存在通行密钥）。此外，您可以直接选择一个已知设备以使用那里的通行密钥。

该模态框与 Windows 上 Chrome 119 的对应版本有很大不同。

这是预期的行为，因为我们只允许使用内部通行密钥，但在设备上找不到内部凭据（我们不允许使用混合通行密钥）。通行密钥身份验证在此步骤失败，在实际实现中，您需要提供备用身份验证方法。

没有匹配的本地通行密钥，因此建议扫描二维码或使用硬件安全密钥（例如 YubiKey）/跨平台验证器/漫游验证器。此外，您可以直接选择一个已知设备以使用那里的通行密钥。

该模态框与 Windows 上 Chrome 119 的对应版本有很大不同。

正如预期的那样，所有形式的通行密钥身份验证都是允许的：通过 Touch ID、通过二维码、通过已知设备和通过硬件安全密钥。

正如预期的那样，没有匹配的本地通行密钥，因此建议扫描二维码并在另一台设备上使用通行密钥（因为系统知道该用户存在通行密钥）。

令人困惑的是，即使我们只允许内部凭据，这里也显示了二维码。我们找不到这种行为的合理解释。

没有匹配的本地通行密钥，因此建议扫描二维码或使用硬件安全密钥（例如 YubiKey）/跨平台验证器/漫游验证器。

正如预期的那样，大多数形式的通行密钥身份验证都是允许的：通过 Touch ID、通过二维码和通过硬件安全密钥。出于某种原因，未显示已知设备。

正如预期的那样，没有匹配的本地通行密钥，因此建议扫描二维码并在另一台设备上使用通行密钥（因为系统知道该用户存在通行密钥）。

令人困惑的是，即使我们只允许内部凭据，这里也显示了二维码。我们找不到这种行为的合理解释。

没有匹配的本地通行密钥，因此建议扫描二维码或使用硬件安全密钥（例如 YubiKey）/跨平台验证器/漫游验证器。

正如预期的那样，大多数形式的通行密钥身份验证都是允许的：通过 Face ID、通过二维码和通过硬件安全密钥。出于某种原因，未显示已知设备。

正如预期的那样，没有匹配的本地通行密钥，因此建议扫描二维码并在另一台设备上使用通行密钥（因为系统知道该用户存在通行密钥）。

令人困惑的是，即使我们只允许内部凭据，这里也显示了二维码。我们找不到这种行为的合理解释。

没有匹配的本地通行密钥，因此建议扫描二维码或使用硬件安全密钥（例如 YubiKey）/跨平台验证器/漫游验证器。

正如预期的那样，大多数形式的通行密钥身份验证都是允许的：通过 Face ID、通过二维码和通过硬件安全密钥。出于某种原因，未显示已知设备。

接下来，对于 Windows 10 设备，我们决定更进一步，分析在 Windows 10 机器上禁用或通常不可用蓝牙时的行为。特别是对于较旧的台式机设备，这仍然是一种非常常见的情况，因为这些设备通常没有蓝牙模块，因此无法通过二维码和蓝牙进行跨平台身份验证。

8.8.1.1 transports: [internal, hybrid]

正如预期的那样，没有匹配的本地通行密钥，因此建议在另一台设备上使用通行密钥（因为系统知道该用户存在通行密钥 - 第一张截图）或选择扫描二维码（第二张截图）。

8.8.1.2 transports: [internal]

令人困惑的是，系统会提示您输入 Windows Hello PIN 码（或如果设备上设置了指纹/面部扫描），即使我们更改了凭据 ID（因此它实际上不应该找到凭据，因为它没有在 allowCredentials 属性中指定）。然而，在提交 Windows Hello PIN 码后，会抛出一个错误：“NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client.” 从用户角度来看，这是一个相当令人困惑的行为，但这是有道理的，因为这可能会在未经用户同意的情况下提供有关用户通行密钥的信息。

8.8.1.3 未设置 transports 属性

没有匹配的本地通行密钥，因此建议扫描二维码或使用硬件安全密钥（例如 YubiKey）/跨平台验证器/漫游验证器。

8.8.1.4 空的 allowCredentials

正如预期的那样，所有形式的通行密钥身份验证都是允许的：通过 Windows Hello、通过二维码、通过已知设备和通过硬件安全密钥。

8.8.2.1 transports: [internal, hybrid]

这对用户来说是一个非常令人困惑的消息，因为它没有明确说明他们应该做什么以及如何进行身份验证。他们唯一的选择是点击“取消”，使这种情况成为一个死胡同。

8.8.2.2 transports: [internal]

此行为与启用蓝牙时的情况相同。非常令人困惑的是，用户被提示输入 Windows Hello PIN 码（或如果设备上设置了指纹/面部扫描），即使我们更改了凭据 ID（因此它实际上不应该找到凭据，因为它没有在 allowCredentials 属性中指定）。然而，在提交 Windows Hello PIN 码后，会抛出一个错误：“NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client.” 从用户角度来看，这是一个相当令人困惑的行为，但这是有道理的，因为这可能会在未经用户同意的情况下提供有关用户通行密钥的信息。

8.8.2.3 未设置 transports 属性

没有匹配的本地通行密钥，因此您唯一的选择是使用硬件安全密钥（例如 YubiKey）/跨平台验证器/漫游验证器。

8.8.2.4 空的 allowCredentials

通行密钥身份验证只能通过 Windows Hello 和硬件安全密钥进行。

8.9.1.1 transports: [internal, hybrid]

正如预期的那样，没有匹配的本地通行密钥，因此建议扫描二维码并在另一台设备上使用通行密钥（因为系统知道该用户存在通行密钥）。

8.9.1.2 transports: [internal]

令人困惑的是，系统会提示您输入 Windows Hello PIN 码（或如果设备上设置了指纹/面部扫描），即使我们更改了凭据 ID（因此它实际上不应该找到凭据，因为它没有在 allowCredentials 属性中指定）。然而，在提交 Windows Hello PIN 码后，会抛出一个错误：“NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client.” 从用户角度来看，这是一个相当令人困惑的行为，但这是有道理的，因为这可能会在未经用户同意的情况下提供有关用户通行密钥的信息。

8.9.1.3 未设置 transports 属性

没有匹配的本地通行密钥，因此建议扫描二维码或使用硬件安全密钥（例如 YubiKey）/跨平台验证器/漫游验证器。

8.9.1.4 空的 allowCredentials

正如预期的那样，所有形式的通行密钥身份验证都是允许的：通过 Windows Hello、通过二维码和通过硬件安全密钥。出于某种原因，未显示已知设备。

8.9.2.1 transports: [internal, hybrid]

这对用户来说是一个非常令人困惑的消息，因为它没有明确说明他们应该做什么以及如何进行身份验证。他们唯一的选择是点击“取消”，使这种情况成为一个死胡同。

8.9.2.2 transports: [internal]

此行为与启用蓝牙时的情况相同。非常令人困惑的是，用户被提示输入 Windows Hello PIN 码（或如果设备上设置了指纹/面部扫描），即使我们更改了凭据 ID（因此它实际上不应该找到凭据，因为它没有在 allowCredentials 属性中指定）。然而，在提交 Windows Hello PIN 码后，会抛出一个错误：“NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client.” 从用户角度来看，这是一个相当令人困惑的行为，但这是有道理的，因为这可能会在未经用户同意的情况下提供有关用户通行密钥的信息。

8.9.2.3 未设置 transports 属性

没有匹配的本地通行密钥，因此您唯一的选择是使用硬件安全密钥（例如 YubiKey）/跨平台验证器/漫游验证器。

8.9.2.4 空的 allowCredentials

通行密钥身份验证只能通过 Windows Hello 和硬件安全密钥进行。

8.10.1.1 transports: [internal, hybrid]

正如预期的那样，没有匹配的本地通行密钥，因此建议扫描二维码并在另一台设备上使用通行密钥（因为系统知道该用户存在通行密钥）。

8.10.1.2 transports: [internal]

令人困惑的是，系统会提示您输入 Windows Hello PIN 码（或如果设备上设置了指纹/面部扫描），即使我们更改了凭据 ID（因此它实际上不应该找到凭据，因为它没有在 allowCredentials 属性中指定）。然而，在提交 Windows Hello PIN 码后，会抛出一个错误：“NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client.” 从用户角度来看，这是一个相当令人困惑的行为，但这是有道理的，因为这可能会在未经用户同意的情况下提供有关用户通行密钥的信息。

8.10.1.3 未设置 transports 属性

没有匹配的本地通行密钥，因此建议扫描二维码或使用硬件安全密钥（例如 YubiKey）/跨平台验证器/漫游验证器。

8.10.1.4 空的 allowCredentials

正如预期的那样，所有形式的通行密钥身份验证都是允许的：通过 Windows Hello、通过二维码和通过硬件安全密钥。出于某种原因，未显示已知设备。

8.10.2.1 transports: [internal, hybrid]

这对用户来说是一个非常令人困惑的消息，因为它没有明确说明他们应该做什么以及如何进行身份验证。他们唯一的选择是点击“取消”，使这种情况成为一个死胡同。出于某种原因，Windows 安全模态框的部分内容也以德语显示（此设备上安装的第二语言）。

8.10.2.2 transports: [internal]

此行为与启用蓝牙时的情况相同。非常令人困惑的是，用户被提示输入 Windows Hello PIN 码（或如果设备上设置了指纹/面部扫描），即使我们更改了凭据 ID（因此它实际上不应该找到凭据，因为它没有在 allowCredentials 属性中指定）。然而，在提交 Windows Hello PIN 码后，会抛出一个错误：“NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client.” 从用户角度来看，这是一个相当令人困惑的行为，但这是有道理的，因为这可能会在未经用户同意的情况下提供有关用户通行密钥的信息。

8.10.2.3 未设置 transports 属性

没有匹配的本地通行密钥，因此您唯一的选择是使用硬件安全密钥（例如 YubiKey）/跨平台验证器/漫游验证器。

8.10.2.4 空的 allowCredentials

通行密钥身份验证只能通过 Windows Hello 和硬件安全密钥进行。

8.11.1.1 transports: [internal, hybrid]

正如预期的那样，没有匹配的本地通行密钥，因此建议扫描二维码并在另一台设备上使用通行密钥（因为系统知道该用户存在通行密钥）。

8.11.1.2 transports: [internal]

令人困惑的是，系统会提示您输入 Windows Hello PIN 码（或如果设备上设置了指纹/面部扫描），即使我们更改了凭据 ID（因此它实际上不应该找到凭据，因为它没有在 allowCredentials 属性中指定）。然而，在提交 Windows Hello PIN 码后，会抛出一个错误：“NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client.” 从用户角度来看，这是一个相当令人困惑的行为，但这是有道理的，因为这可能会在未经用户同意的情况下提供有关用户通行密钥的信息。

8.11.1.3 未设置 transports 属性

没有匹配的本地通行密钥，因此建议扫描二维码或使用硬件安全密钥（例如 YubiKey）/跨平台验证器/漫游验证器。

8.11.1.4 空的 allowCredentials

正如预期的那样，所有形式的通行密钥身份验证都是允许的：通过 Windows Hello、通过二维码和通过硬件安全密钥。出于某种原因，未显示已知设备。

8.11.2.1 transports: [internal, hybrid]

这对用户来说是一个非常令人困惑的消息，因为它没有明确说明他们应该做什么以及如何进行身份验证。他们唯一的选择是点击“取消”，使这种情况成为一个死胡同。

8.11.2.2 transports: [internal]

此行为与启用蓝牙时的情况相同。非常令人困惑的是，用户被提示输入 Windows Hello PIN 码（或如果设备上设置了指纹/面部扫描），即使我们更改了凭据 ID（因此它实际上不应该找到凭据，因为它没有在 allowCredentials 属性中指定）。然而，在提交 Windows Hello PIN 码后，会抛出一个错误：“NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client.” 从用户角度来看，这是一个相当令人困惑的行为，但这是有道理的，因为这可能会在未经用户同意的情况下提供有关用户通行密钥的信息。

8.11.2.3 未设置 transports 属性

没有匹配的本地通行密钥，因此您唯一的选择是使用硬件安全密钥（例如 YubiKey）/跨平台验证器/漫游验证器。

8.11.2.4 空的 allowCredentials

通行密钥身份验证只能通过 Windows Hello 和硬件安全密钥进行。

• 使用库和框架来抽象纯 WebAuthn API 的一些复杂性。
• 从一开始就考虑跨平台身份验证场景，以确保广泛的用户群可以从您的通行密钥实施中受益。根据您的设计选择，您还可以在这些场景中提供替代登录方法。
• 为由于设备限制可能无法进行通行密钥跨平台身份验证（混合传输）的场景开发回退机制。
• 最大的设计决策是决定是否要推广通过二维码/蓝牙（混合传输）的跨平台通行密钥身份验证，并使其成为通行密钥身份验证的突出方法，或者使用提示来不主动推广它。在后一种情况下，总是尝试立即使用内部存储的通行密钥，只有在找不到内部通行密钥时，才会显示用于跨平台身份验证（混合传输）的二维码。这需要在您的 WebAuthn 服务器选项的 excludeCredentials 和 allowCredentials 属性中定义。在您的 WebAuthn 服务器的 excludeCredentials 属性中，您可以看到有关已创建凭据的传输信息。在 allowCredentials 属性中，您可以指定登录过程中的行为（参见上文的测试）。
• 此外，您无法完全阻止跨平台通行密钥身份验证（混合传输）（参见上面使用 transports: [internal] 的测试），因此您需要准备好您的用户会找到这种方法并会有疑问。这种跨平台身份验证（混合传输）的出现尤其会在用户开始在本地删除通行密钥时发生。

• 创建全面的指南和教程，引导用户完成通行密钥跨平台身份验证（混合传输）过程。
• 使用应用内工具提示和上下文帮助部分来指导用户完成他们的第一次通行密钥跨平台身份验证（混合传输）体验。
• 在您的网站或应用程序内提供常见问题解答和故障排除部分。

• 为通过二维码或蓝牙的通行密钥登录实施有时间限制的会话，以确保访问只是临时的和安全的。
• 确保通行密钥跨平台身份验证（混合传输）不会破坏任何现有的安全协议，保持用户数据的完整性。
• 考虑隐私影响，并确保通过通行密钥跨平台身份验证（混合传输）授予的任何临时访问都根据安全最佳实践进行记录和监控。

通过二维码/蓝牙（混合传输）进行通行密钥跨平台身份验证在安全性和用户体验之间提供了一种平衡。然而，这对大多数用户来说是一个全新的过程，可能会导致许多令人困惑的情况，因此需要仔细考虑是否要推广它。

我们希望我们能够对通过二维码/蓝牙进行通行密钥跨平台身份验证（混合传输）的主题有所阐明，解释如何进行设置以及在不同设备/浏览器组合上的行为。如果您有任何问题，请随时通过我们的通行密钥社区与我们联系，或订阅我们的通行密钥 Substack。让我们通过推广通行密钥，让互联网成为一个更安全的地方。