How passkeys work: Let’s start the passkey registration process
您的Passkey之旅可能是一次陌生且不一致的考验。但并非必须如此。
认证器与密码管理器的区别
在继续Passkey之旅之前，区分认证器（authenticator）和密码管理器（password manager）至关重要。
在Passkey世界中，认证器是一种技术，不仅创建和存储Passkey的公私钥组件，还在任何认证仪式中检索Passkey。这可以是密码管理器——例如内置在网页浏览器中的Google密码管理器，或第三方自带密码管理器（如Bitwarden、Dashlane或NordPass）。 Alternatively，认证器可能涉及设备操作系统和任何本地安全硬件的组合，例如可信平台模块（TPM）、安全飞地（secure enclave），或第三方符合FIDO2标准的漫游认证器（如Yubico的Yubikey之一（其本身不是密码管理器））。
重要的是，虽然当今大多数密码管理器是符合FIDO2标准的认证器，但并非所有认证器（例如Yubikey）都是密码管理器。此外，请记住，“认证器”一词对不同技术供应商及其客户意味着不同的事物。虽然Google Authenticator用于生成时间型一次性密码（TOTP）作为多因素认证的一种形式，并且目前与Passkey无关，但Microsoft Authenticator是一个密码管理器、TOTP生成器和有限的Passkey认证器，全部集成在一个产品中。然而，作为向行业发出的信号，Microsoft希望消除世界上的密码，转而支持Passkey，Microsoft即将放弃其认证器对密码的支持。行业不必要地使“认证器”一词变得混乱。
FIDO联盟是一个由组织（包括Apple、Google和Microsoft）组成的联盟，维护和推广认证标准以减少对密码的依赖。2021年，在揭示其符合FIDO2标准的凭证实现过程中，Apple将其称为“passkeys”，此后这个名称一直沿用。
广泛的认证器选择和类型说明了每个用户和组织在规划其Passkey之旅时必须做出的一些重要决策。我的Top 10 Passkey Survival Tips涵盖了一些规划想法。
在您的更大图景Passkey策略方面，请注意您可以为不同的Passkey使用不同的认证器。例如，虽然我使用Bitwarden作为我访问的大多数网站的认证器，但我为我的Bitwarden账户配置了YubiKey作为认证器。此外，大多数依赖方允许您为同一账户创建多个Passkey。就我而言，我为我的Gmail账户配置了两个Passkey，每个都依赖于不同的漫游认证器。
启动Passkey注册仪式
好了，继续我们的旅程。
一旦点击依赖方的“创建Passkey”按钮，Passkey注册仪式就开始了。端到端过程涉及一些非常明显的用户界面元素以及一些在幕后发生的非常技术性的东西。我将涵盖两者。
当依赖方的服务器收到您想要启动Passkey注册仪式的指示时，服务器透明地响应您的网页浏览器，提供一个时间敏感的提议（正式称为PublicKeyCredentialCreationOptions），包含WebAuthn凭证配置选项，供您的浏览器和任何认证器遵循。请记住（从本系列的第1部分），凭证最终是Passkey，但Passkey本身是一种WebAuthn凭证。
在此提议中，某些参数的作用是安全地为您创建一个Passkey，仅用于一个依赖方。一旦创建，它不能像您的密码那样用于登录到冒名顶替的网站。因此，与密码不同——密码从您首次创建并与依赖方共享的那一刻起（以及其余生）相对不安全——Passkey从出生起就是安全的，部分原因是这些凭证创建选项。
除了包括一个机器生成的非人类可读的用户ID（从此处起称为user.id），该ID对用户是唯一的（并可在后续认证仪式中使用），PublicKeyCredentialCreationOptions中的另一个包含是rpId——本质上是依赖方的身份。此字段的内容（互联网域或子域）必须与您设备浏览器视为上述服务器响应来源域的原始域（例如“shopify.com”）匹配。（它使用与您浏览器用于双重检查其接收的任何流量来源相同的完整性检查机制。）如果省略此字段，rpId默认为浏览器观察到的原始域。
在注册仪式的此时包含rpId有两个重要原因。首先，如果rpId与原始域不匹配，注册应该失败。它本质上意味着“可能存在恶意行为”。因此，恶意域无法欺骗最终用户注册一个广告为一个域工作的Passkey，而实际上它为另一个域工作（或反之亦然）。然而，此测试的必要性（以及任何由此产生的红旗）不如后续登录尝试（即认证仪式）期间的另一个测试重要。
在注册仪式期间，当依赖方成功将其rpId报告给认证器（换句话说，rpId匹配刚刚描述的原始域）时，认证器将新Passkey的范围限定仅用于该rpId。换句话说，它只能作为Passkey在创建它的域上工作。对于密码，用户可能被欺骗向恶意网站或应用程序提供其登录凭据。对于Passkey则不会。这是因为，如本系列第5部分所述，您的认证器甚至不会尝试使用为一个原始域 intended 的Passkey来认证另一个域。
PublicKeyCredentialCreationOptions列表中的另一个重要安全元素是一个随机生成的字符串，称为“挑战”（challenge）。此字符串特定于您设备网页浏览器与依赖方服务器之间的当前会话——注册Passkey的会话——并提供保证，该会话不会被恶意行为者拦截并在以后重放。
除了这些安全预防措施，PublicKeyCredentialCreationOptions使依赖方能够允许某些认证器类型并禁止其他类型，同时还指定用户在提议过期之前有多少时间（以毫秒为单位）响应。例如，超时设置30,000毫秒允许用户有30秒的时间，然后注册Passkey的提议（包含挑战） essentially 被撤回。
依赖方还可以（可选地）要求用户在尝试使用新创建的Passkey登录时提供指纹、面部ID或PIN。但根据我的经验，一些依赖方不执行此选项。即使他们执行，认证器也没有义务尊重它。
无论哪种方式，这是Passkey道路上的一个分叉点，用户体验的重要部分留给依赖方——并非所有依赖方都会做出相同的选择。
在可预见的未来，Passkey注册仪式（以及整体Passkey用户体验）中 resulting 的不一致将成为最终用户的困惑来源和Passkey采用的障碍。
在工作流的此时，当您表示想要创建Passkey时，依赖方将要求您重新认证（见下图截图），作为对恶意行为者尝试为您的账户创建一个的额外预防措施。然而，关于此步骤的用户体验因依赖方而异。一些依赖方不需要重新认证；其他需要您的密码进行认证，即使您可能之前已经注册了Passkey。（为什么不能使用那个Passkey？）
在Shopify的情况下，如果您已经注册了Passkey，您可以选择使用该Passkey或您的密码重新认证。下图截图仅显示密码选项，因为没有先前注册的Passkey。
重新认证后，您会被告知浏览器或设备将在您点击继续按钮后提示您创建Passkey，如下所示。并非所有依赖方都将此提示作为Passkey注册仪式的一部分。
Passkey主要基于公钥密码学，其中每个Passkey涉及一个公钥和一个私钥。后者是一个秘密，从不以与密码相同的方式与依赖方共享。Passkey的最大安全好处，包括其防钓鱼和防smishing能力，都锚定在这一最重要的方面：秘密始终与您，用户，在一起。
一旦网页浏览器从依赖方收到创建Passkey的指令，它必须确定使用哪个认证器来创建它。为此，浏览器必须首先确定当时有哪些认证器可用。类似于用户可以选择配置其操作系统以通过默认网页浏览器响应所有网页请求的方式，用户应该能够指示他们选择默认认证器来处理所有认证请求——并有一个选项在用户认为必要时覆盖该选择。不幸的是，用户没有分配默认认证器的选项， resulting 的Passkey用户体验不一致是Passkey生态系统的主要缺点之一。
认证选项丰富
例如，下面的部分截图显示了一种场景，我安装了Bitwarden密码管理器的Chrome扩展来处理我的认证（红色箭头），同时通过Chrome设置禁用Google密码管理器（绿色箭头）。
理论上，当我点击Shopify的“创建Passkey按钮”时，它应该基于Bitwarden扩展的存在假设Bitwarden是我首选的认证器。毕竟，扩展已安装。然而，为了让Chrome检测到Bitwarden扩展（或任何其他认证器）的存在，扩展必须首先向Chrome注册其作为认证器的可用性——这只有在它处于活动状态时才能做到。从Bitwarden图标的灰色可以看出，Bitwarden当前处于非活动状态（我尚未登录）。因此，它此刻未向Chrome注册为可用认证器。此时，Chrome与操作系统检查以了解它知道哪些认证器，由于它是运行MacOS的Mac，操作系统首先提供以下 highly 误导性的对话框。
尽管对话框说，您不需要启用iCloud钥匙串来保存您的Passkey。只有当iCloud钥匙串（又名Apple密码）是您创建和保存此和/或其他Passkey的首选认证器时才需要它。即使它没有意义并且可能是一个巨大的困惑来源（特别是对于Mac用户），可用认证器选项的完整列表实际上隐藏在取消按钮后面。
点击取消按钮后，控制权返回给Chrome，后者依次呈现下图对话框中显示的选项，其中之一是iCloud钥匙串。换句话说，先前的对话框不仅令人困惑而且不必要。
虽然详细探索上面列出的所有选项超出了本文的范围（此步骤的主要点是从可用认证器选项中选择一个），但值得一提的是，当您看到“安全密钥”作为认证器选项时，它指的是漫游认证器。示例包括Yubico的Yubikey 5 NFC和Google的Titan安全密钥。
同样重要的是要注意，Chrome配置文件选项计划被弃用。Google发言人告诉ZDNET：“这只是一个我们计划逐步淘汰的临时解决方案，但它在Passkey之前的世界中最初是有帮助的。为了使Passkey体验更加无缝，我们一直在投资同步以确保它们跨设备和平台可用。这现在是标准的用户体验。”
该投资一直在Google密码管理器作为“平台”认证器，在我的第二个场景中，基于以下系列截图，它显示为可用选项。在这些截图的第一个中，Bitwarden仍然处于非活动状态。但是，在Chrome设置中，Google的密码管理器被切换为开启，如绿色箭头所示。
即使Google密码管理器被切换为开启，当需要创建Passkey时，MacOS仍然坚持首先将iCloud钥匙串呈现为唯一可用选项，如先前上面所示。然而，这次当点击取消按钮时，Google密码管理器现在被列为可用选项，如下面部分截图中的绿色箭头所示。
在这第三个也是最后一个场景中，Google密码管理器被切换为关闭。但是，Bitwarden扩展的图标现在以蓝色和白色照亮，因为我通过输入我的Bitwarden密码激活了它。换句话说，Google密码管理器不再可用作平台认证器，但Bitwarden现在已向Chrome注册自己为可用的第三方认证器，这进而触发了完全不同的用户体验。万维网联盟（W3C）的WebAuthn标准正式将此类第三方认证器称为虚拟认证器。
这次，在点击依赖方网站上的“创建Passkey”按钮后，iCloud钥匙串对话框和浏览器显示可用认证器列表的对话框都被绕过，Bitwarden浏览器扩展如以下截图所示活跃起来。
如上所示，Bitwarden扩展处于活动状态但被锁定。请注意，BitWarden的锁定状态与其非活动状态非常不同。当它被锁定时，扩展处于活动状态但仍需要用户使用密码、PIN或指纹解锁。
一旦Bitwarden被解锁，注册仪式将继续。然而，如果您的Passkey策略涉及多个认证器并且您希望使用默认认证器以外的认证器，您必须首先关闭认证器的弹出窗口。此时，工作流自动重新开始。然而，如果用户到达浏览器的可用认证器列表，像Bitwarden扩展这样的虚拟认证器——奇怪地、可悲地和不一致地——不在其中。
请注意，当使用像Bitwarden这样的第三方扩展作为您的虚拟认证器时，您可能应该避免上面截图所示的场景，其中认证器的扩展和Google密码管理器（或其他浏览器中的等效平台认证器）同时被激活。当这种情况发生时，用户很可能会遇到竞争性、令人困惑且有时重叠的自动填充对话框，因为现在浏览器 essentially 正在接收关于您认证器选择的冲突信号。
在下一部分中，我们将深入探讨Passkey创建过程的幕后， magic 真正发生的地方。
通过Tech Today保持安全新闻领先，每天早晨发送到您的收件箱。