了解将通行密钥与本地生物识别技术结合使用的好处,以实现最佳的应用安全性和无缝的用户访问体验。
Vincent
Created: June 17, 2025
Updated: July 8, 2025
See the original blog version in English here.
Our mission is to make the Internet a safer place and passkeys provide a superior solution to achieve that. That's why we want to keep you updated with the latest industry insights here.
随着手机生物识别技术成为主流,许多原生应用开始使用面容 ID 或触控 ID(或安卓系统的同类功能)等功能来保护应用访问。这种本地生物识别保护通过允许快速无缝的访问,极大地提升了用户便利性。乍一看,通行密钥和本地生物识别似乎有些多余,因为两者都涉及验证用户。但它们服务的目的根本不同。本文将探讨:
读完本文,我们将更好地理解何时以及如何将这些解决方案结合起来,以创造更安全、更用户友好、更无缝的应用体验。我们还将概述结合通行密钥和本地生物识别可以增强安全性和便利性的实际场景,确保开发者能够做出明智的决策,有效满足用户需求。
本地生物识别认证方法,如苹果的面容 ID、触控 ID 或安卓的生物识别功能,利用独特的生理特征(例如,面部特征或指纹)来验证用户身份。与依赖用户所知信息(如传统 PIN 码或密码)不同,生物识别依赖于用户固有的特征。这一转变消除了重复输入代码的需要,显著减少了摩擦,使日常应用访问既快速又安全。
在生物识别技术在手机上获得主流关注之前,旨在保护敏感内容的应用通常要求用户每次启动时输入一个额外的 PIN 码或密码。虽然这种方法提高了安全性,但也带来了额外的不便,特别是当用户在会话开始时已经通过认证的情况下。基于设备的面部识别和指纹扫描技术的出现简化了这一过程。用户现在可以通过快速的面部扫描或短暂的触摸来解锁应用,而无需重复输入代码。如果出于任何原因,生物识别检查失败或用户不愿启用它,仍然可以使用备用的 PIN 码、通行码或密码。这种设计在不牺牲安全性的前提下,确保了便利性和可访问性。
区分本地生物识别检查和完整的远程认证事件至关重要。远程认证发生在新会话开始时,使用密码或通行密钥等凭证,对照服务的后端系统验证用户身份。这一步在用户和服务之间建立信任。
相比之下,本地生物识别专注于在持续的、已认证的会话中重新验证身份。当用户短暂离开应用或锁定手机时,本地生物识别会确认仍然是同一个授权用户在控制设备,而不是要求用户重新输入密码或其他凭证。这种以设备为中心的验证不需要互联网连接或与远程服务器交互,使其在日常使用中快速、可靠且无缝。
生物识别数据在专用的硬件安全模块内安全地存储和处理——例如 iOS 上的安全隔区 (Secure Enclave) 或安卓上的可信执行环境 (TEE)。这些可信模块旨在保护敏感的生物识别数据免受篡改、提取或转移。
由于这种硬件级别的锚定,生物识别验证无法轻易地在设备或服务之间共享。每个设备的生物识别模板对该特定单元都是唯一的,确保如果用户升级到新手机,他们必须从头开始重新注册其生物识别信息。虽然这在更换设备时增加了一个小的上手步骤,但它能防范未经授权的访问,并防止可能利用集中存储的生物识别数据的远程攻击。此外,本地生物识别无需互联网连接即可工作,即使设备离线也同样可靠。
本地生物识别通过验证当前操作设备的人确实是合法的、已认证的用户,简化了安全性,无需在应用具有银行、保险或其他个人详细信息等重要功能时重复输入自定义 PIN 码或密码。
它们通过在设备上无缝、即时地工作来保持便利性,可以离线操作,并依赖安全的硬件隔区来保护敏感的生物识别数据。虽然它们不能取代建立用户身份所需的初始远程认证(如通行密钥或密码),但它们非常擅长管理和保护后续的、持续的会话。
它们的局限性,如缺乏可移植性和需要在新设备上重新注册,是为了增强便利性和严格的设备级安全性而做出的权衡。最终,一旦信任初步建立,本地生物识别便成为一种强大、用户友好的方法,用于确保应用会话中的持续信任。
通行密钥通过用非对称加密凭证取代密码等共享密钥,改变了认证的本质。与仅在本地验证已认证用户的本地生物识别不同,通行密钥是向远程服务识别用户的主要方法。这确保了即使在用户和设备对应用程序后端最初未知的情况下,也能提供安全、防网络钓鱼的登录体验。
在通行密钥出现之前,与远程服务建立信任的常用方法涉及密码——用户和服务器都知道的共享密钥。虽然密码实现简单,但它们容易受到网络钓鱼、凭证填充和密码重用等威胁的攻击。
通行密钥通过使用一对加密密钥来解决这些挑战:一个安全存储在用户设备上的私钥,以及一个在服务处注册的相应公钥。当发生登录尝试时,服务会发送一个只有用户私钥才能解决的挑战。这确保了即使攻击者截获数据或试图诱骗用户泄露凭证,他们也无法获得未经授权的访问。
通行密钥采用非对称加密:
这对于除了原生应用外还使用网站的系统尤其重要,因为在网站上,网络钓鱼是一个大问题。在移动设备上创建的通行密钥也可以通过跨设备认证在桌面电脑的网站上使用。
通行密钥的核心优势之一是其在用户设备间的无缝可移植性。现代操作系统可以通过安全的云存储(例如,iCloud 钥匙串、谷歌密码管理器)同步通行密钥,使用户能够从多个设备登录,而无需重新注册或记住密码,即可首次安装应用。此外,通行密钥还可用于需要第二因素的场景,提供类似双因素的保护,而不会增加摩擦。这种协同作用无论用户选择哪个设备,都能实现快速、安全的登录,从而巩固了一个安全认证既普遍可及又易于维护的生态系统。
通行密钥代表了一种强大的、防网络钓鱼的、用于向远程服务认证未知用户的方法。通过利用非对称加密并从共享密钥转向驻留在设备上的私钥,它们消除了困扰基于密码的系统的许多弱点。通行密钥结合了强大的安全性、全球可移植性以及与硬件安全组件的直接集成。因此,它们为建立用户身份奠定了坚实的基础——这是单靠本地生物识别无法提供的。在原生应用的背景下,通行密钥是创建安全会话的关键第一步,之后可以采用本地生物识别来维持快速便捷的用户访问。
在原生应用的认证方面,通行密钥和本地生物识别扮演着重要但不同的角色。虽然它们都改善了用户体验和安全性,但它们解决了根本不同的问题:
理解这些差异对于旨在创建既安全又用户友好的强大认证流程的开发者至关重要。
为了更好地理解通行密钥和本地生物识别的区别和互补作用,下表比较了它们在各个维度的关键特征,包括目的、使用场景、安全性和可移植性。这个比较突出了这些技术如何解决根本不同的问题,同时共同增强安全性和用户便利性。
方面 | 通行密钥 | 本地生物识别 |
---|---|---|
阶段 | 应用安装后 重新登录 会话超时 | 应用已安装并登录 |
核心目的 | 认证未知用户(初始登录) | 验证当前活跃用户(已认证)是设备/应用的合法所有者 |
保护对象 | 用户账户的访问权限 | 已登录应用的访问权限 |
使用场景 | 适用于首次登录或重新安装后,与服务建立信任,以及实现跨平台、跨设备登录 | 适用于重新验证设备持有者是否为设备所有者,快速解锁应用而无需重新输入密码/通行密钥 |
认证模型 | 远程认证:对照后端系统验证身份 | 本地验证:检查安全存储在设备上的生物识别数据,不联系远程服务器 |
多因素认证 | 是 + 防网络钓鱼 | 否 |
原生生物识别 | 是(例如面容 ID、触控 ID、安卓生物识别) | 是(例如面容 ID、触控 ID、安卓生物识别) |
范围与可移植性 | 跨设备、跨平台、跨应用可用性(原生应用 + 网站),得益于密钥的安全云同步 | 特定于设备,不可转移:生物识别模板必须在新设备上重新注册 无法轻易在平台间移动 |
数据存储与安全 | 私钥存储在安全隔区 公钥存储在服务器端 不传输共享密钥 防网络钓鱼 | 生物识别模板存储在设备上的安全硬件隔区 永不离开设备 受设备硬件保护 |
网络要求 | 需要互联网连接以与远程服务认证并注册密钥 | 无需互联网连接;验证完全在本地进行,使其在离线时和应用有离线用例时很有用 |
备份与恢复 | 密钥可通过云同步(例如 iCloud 钥匙串、谷歌密码管理器)备份和恢复,确保在设备丢失或更换时轻松恢复 | 生物识别没有内置备份机制;如果设备出现故障,用户必须在新设备上重新注册其生物识别数据 |
与网站和应用的集成 | 可用于原生应用和网站。通行密钥通过在不泄露凭证的情况下认证用户来简化登录流程,从而全面增强安全性 | 仅限于本地安装的设备和应用 |
开发者实现 | 使用网络标准(WebAuthn、FIDO2)和原生平台 API 进行集成 后端必须处理公钥和挑战 | 利用平台 SDK(iOS、安卓)进行生物识别提示 无需特殊的后端处理 |
用户体验 | 初始设置后,用户可以快速登录,无需记住电子邮件或密码,即使在新设备上也是如此 通过减少摩擦简化了上手流程 | 一旦用户已经认证,提供即时、无密码的重新访问应用的方式 |
虽然上表突出了核心差异,但认识到通行密钥和本地生物识别并非相互竞争的技术——它们是互补的,这一点很重要。它们共同提供了一种分层的认证体验:
通过结合通行密钥和本地生物识别,开发者可以提供一个安全、无缝且用户友好的认证流程。
通过结合通行密钥和本地生物识别,开发者可以创建一个强大的认证流程,从而:
这种协同作用确保了应用既能提供强大的认证,又能提供无缝的便利性——这是满足现代用户期望的制胜组合。
为了更好地理解真实世界的示例和组合如何运作,我们将研究两种不同的实现方式:一种仅利用通行密钥,另一种则采用组合方法。
Kayak 应用展示了使用通行密钥进行用户认证的实现。通行密钥无缝集成到登录过程中,为用户提供了无需记住电子邮件地址或密码即可认证的选项。如认证屏幕所示,用户可以直接选择一个通行密钥进行登录。这种方法通过减少认知负荷和消除与密码相关的摩擦,显著简化了用户体验。
通过通行密钥认证后,用户可以无限制地访问应用,无需重新认证。这种设计特别适用于 Kayak,这是一个主要管理预订历史和行程的旅行应用,这些数据不被认为是高度敏感或关键数据。
Kayak 方法的主要亮点:
这个实现展示了通行密钥如何简化认证过程,同时消除了对密码的需求,为用户提供了无缝的体验。然而,在应用内执行更敏感或关键操作的场景中,可能需要额外的安全层,例如本地生物识别。让我们探讨一下 GitHub 如何利用通行密钥和生物识别来确保安全性而不影响可用性。
GitHub 在集成通行密钥以实现安全登录与使用本地生物识别保护登录状态下的应用内容之间取得了平衡。通行密钥作为一种快速、防网络钓鱼的登录选项提供,考虑到 GitHub 的多因素认证 (MFA) 要求,这一点尤其重要。这消除了用户管理密码或一次性密码的需要,提供了无缝且安全的登录体验。但为了本文的目的,我们不会关注他们的通行密钥实现。
GitHub 通过本地生物识别增加安全层: 由于 GitHub 还提供合并拉取请求等敏感操作,GitHub 允许用户在认为有必要时启用本地生物识别保护。在此示例中,面容 ID 用于锁定 iOS 上的应用,确保只有设备所有者才能访问或执行 GitHub 应用。该应用明确向操作系统请求激活生物识别所需的权限,并提供可配置的间隔(例如,立即或在定义的超时后)。
GitHub 方法的主要亮点:
总之,这些示例说明了如何根据不同应用的需求量身定制通行密钥和本地生物识别,平衡用户便利性与适当的安全措施。
以下是针对可能实施本地生物识别和通行密钥的常见场景量身定制的四项建议。这些建议的结构使开发者、产品经理和决策者能够快速确定哪种方法最适合他们的情况。随后附有一个总结表,可以轻松地将每个建议映射到给定的场景:
虽然上述建议涵盖了一系列常见场景,但在无数其他情况下,选择实施本地生物识别、通行密钥或两者兼而有之可能会有所不同。每个应用程序都有独特的安全性、可用性和合规性需求,开发者、产品经理和业务领导者在确定方法之前,必须彻底评估这些因素。通过仔细权衡您的特定用例、法规要求和用户期望,您可以制定一个认证策略,不仅能保护您的用户及其数据,还能提供当今客户所期望的无缝、用户友好的体验。
正如我们所见,本地生物识别和通行密钥在现代认证策略中扮演着根本不同但又互补的角色。本地生物识别通过利用用户的固有特征进行快速的设备上检查,简化了持续的会话验证,而通行密钥则与远程服务建立安全且防网络钓鱼的信任关系。通过深思熟虑地结合这些方法,开发者可以创造出既无缝又高度安全的用户体验,有效满足多样化且要求苛刻的数字环境的需求。回到引言中的问题:
通过认识到通行密钥和本地生物识别的独特而又互惠互利的角色,开发者和决策者可以实施一个全面的认证方法,平衡安全性、便利性和用户满意度。这样做,应用程序将更能抵御威胁,更易于导航,并更能适应不断变化的用户和法规要求——最终提供一个无缝且值得信赖的数字环境。
Enjoyed this read?
🤝 Join our Passkeys Community
Share passkeys implementation tips and get support to free the world from passwords.
🚀 Subscribe to Substack
Get the latest news, strategies, and insights about passkeys sent straight to your inbox.
Related Articles
Table of Contents