"密钥登录 "(Passkey )最近很火，它们是 W3C TPAC 2022（万维网联盟技术全体会议和咨询委员会） 大会上的一大亮点，它首先在 Safari 16 中获得了支持，而macOS 和 iOS 正在跟进对它的支持，它也将成为 1Password 等密码管理器的未来。安卓系统已经支持Passkey，Chrome OS 和 Windows 也将在未来的版本中支持这个功能。
上网体验最差的环节，肯定是密码，互联网发展了20多年，所有体验的环节都有巨大改善，只有密码除外，在身份验证环节，目前采用的还是20年前的用法，但让人无奈的是，即使如此麻烦，依然不能杜绝密码被盗、被破解、被钓鱼的风险。
多年来，业界一直努力，试图设计出一套密码的替代方案。近两年终于有了突破，各大公司达成一致，设计出了一套密码的替代方案：密钥登录（Passkey），它将作为一种开放标准，由希望使身份验证更安全、更可用的公司联盟开发。
从本质上讲，密钥只是网站向您的浏览器请求身份验证的一种方式。就是这样，它们不依赖于特定的硬件或该硬件的工作方式。
密钥是一个开放标准。它们不依赖于单一公司，也不依赖于单一公司的实施，而且它是严格离线的，它不需要互联网连接、电话、短信或其他任何东西。这与我们之前对身份验证的认知大相径庭，如果您要对站点进行身份验证，必须首先与服务端建立连接，但这种技术则不需要任何类型的连接。

## 专业术语
下面是我们必须了解的术语部分，和大多数技术一样，Passkeys 也有很多深奥的术语和缩略词，它们往往会成为我们认识了解它的障碍，以下是对相关专业术语的介绍：
- 依赖方：你要进行身份验证的服务器。在本文中，我们将使用 "服务器 "来表示依赖方。
- 客户端：指网络浏览器或操作系统。
- 验证器： 允许生成和存储公钥对的软件和/或硬件设备。
- FIDO：一个开放标准机构，也是围绕 FIDO 凭证创建规范的机构。
- WebAuthn：通行密钥的底层协议，也称为 FIDO2 凭证或单设备 FIDO 凭证。
- 密码钥匙： WebAuthn，但具有云同步功能（也称为多设备 FIDO 凭据、可发现凭据或常驻凭据）。
- 公钥加密： 生成的密钥对，包括私钥和公钥。根据算法的不同，它既可用于签名和验证，也可用于加密和解密。这也被称为非对称加密。
- RSA： 创建者 Rivest Shamir 和 Adel 名字的首字母缩写。RSA 是一种较古老但仍然有用的公钥加密技术，基于因式分解素数。
- 椭圆曲线加密（ECC）： 基于椭圆曲线的较新加密算法系列。
- ES256： 使用 ECDSA 签名算法 (PDF) 和 SHA256 哈希算法的椭圆曲线公钥。
- RS256： 与 ES256 类似，但它使用的是带有 RSASSA-PKCS1-v1.5 和 SHA256 的 RSA。
## 什么是密钥？
在具体讨论通行密钥之前，我们需要先谈谈另一个协议，即 WebAuthn（也称为 FIDO2）。密钥是建立在 WebAuthn 基础上的一种规范。WebAuthn 允许用公钥加密技术取代密码。我们使用某种安全设备（如硬件密钥或可信平台模块（TPM））来创建私钥和公钥。
公钥供任何人使用。而私钥则不能从生成它的设备上移除。这是 WebAuthn 的问题之一；如果你丢失了设备，你就失去了访问权。
Passkeys 通过提供证书的云同步解决了这个问题。换句话说，你在电脑上生成的凭据现在也可以在手机上使用（不过令人困惑的是，也有单设备凭据）。
目前，在撰写本文时，只有 iOS、macOS 和 Android 提供了对云同步密钥的全面支持，即便如此，它们也受到所使用浏览器的限制。谷歌和苹果分别通过谷歌密码管理器和苹果 iCloud Keychain 服务提供了同步接口。
## 通行密钥如何取代密码？
在公钥密码学中，你可以执行所谓的签名。签名是将一段数据用私钥通过签名算法进行处理，然后用公钥进行验证。
任何人都可以生成公钥对，而且公钥对不归属于任何人，因为任何人都可以首先生成公钥对。它的用处在于，只有用私钥签名的数据才能用公钥验证。这就是取代密码的部分--服务器存储公钥，我们通过签署随机挑战书来验证我们是否拥有另一半公钥（如私钥），从而登录。
还有一个好处是，由于我们将用户的公钥存储在数据库中，因此不再担心密码泄露会影响数百万用户。这就减少了网络钓鱼、泄密以及我们这个依赖密码的世界目前面临的一系列其他安全问题。如果数据库被攻破，所有存储在用户公开密钥中的信息对攻击者几乎毫无用处。
也不会再有遗忘的电子邮件和相关密码！浏览器会记住你在哪个网站上使用的凭据--你只需点击几下，就可以登录了。您可以提供使用密钥的辅助验证方式，如生物识别或密码，但这些方式仍比过去的密码快得多。
## 密码学的更多信息
公钥密码学包括一个私人密钥和一个公共密钥（称为密钥对）。密钥是一起生成的，但有不同的用途。例如，私人密钥用于保密，而公开密钥用于与任何人交换信息。
在加密和解密信息时，收件人的公开密钥用于加密信息，只有收件人的私人密钥才能解密信息。在安全术语中，这被称为 "提供机密性"。但是，这并不能证明发件人的身份，因为任何人都有可能使用公开密钥向他人发送加密信息。
在某些情况下，我们需要验证信息确实来自发件人。在这种情况下，我们使用签名和签名验证来确保发件人的身份（也称为真实性）。在公开密钥（也称为非对称）加密中，通常是通过对信息的哈希值进行签名，这样只有公开密钥才能正确验证信息。哈希值和发件人的私人密钥通过算法产生签名，然后任何人都可以用发件人的公开密钥验证信息是否来自发件人。
## 如何访问密钥？
要访问密钥，我们首先需要生成密钥并将其存储在某个地方。其中一些功能可以通过验证器来实现。验证器是任何能够生成加密密钥的硬件或软件支持设备。想想你从 Google Authenticator、1Password 或 LastPass 等软件中获得的一次性密码吧。
例如，软件身份验证器可以使用设备的可信平台模块（TPM）或安全飞地来创建凭证。然后，凭据可以远程存储，并在不同设备间同步，例如通行密钥。像 YubiKey 这样的硬件验证器可以在设备上生成和存储密钥。
要访问验证器，浏览器需要访问硬件，为此我们需要一个接口。我们在这里使用的接口是客户端到验证器协议（CTAP）。它允许通过不同的机制访问不同的验证器。例如，我们可以利用 CTAP 通过 NFC、USB 和蓝牙访问验证器。
使用密码匙的一个更有趣的方法是通过蓝牙将手机连接到另一个可能不支持密码匙的设备上。当设备通过蓝牙配对后，我就可以用手机作为中介登录电脑上的浏览器。
## 通行密钥与 WebAuthn 的区别
通行密钥和 WebAuthn 密钥在几个方面有所不同。首先，通行密钥被视为多设备凭证，可以跨设备同步。相比之下，WebAuthn 密钥是单设备凭据，也就是绑定到一台设备上进行验证的一种花哨说法。
其次，要对服务器进行验证，WebAuthn 密钥需要提供用于登录的用户句柄，然后服务器会向客户端返回一个 allowCredentials（允许凭据）列表，告知哪些凭据可用于登录。Passkeys 跳过了这一步，使用服务器的域名来显示哪些密钥已经绑定到该网站。你可以选择与该服务器相关联的密钥，因为你的系统已经知道了它。
除此之外，密钥的加密方式都是一样的；它们的区别只在于存储方式和启动登录过程时使用的信息。
## 过程简述
生成 WebAuthn 或通行密钥的过程非常相似：从服务器获取一个挑战，然后使用 navigator.credentials.create Web API 生成一对公钥。然后，将挑战和公钥发送回服务器进行存储。
服务器在收到公钥和挑战书后，会验证挑战书和创建挑战书的会话。如果验证通过，公钥以及其他相关信息（如用户标识符或认证数据）就会被存储到数据库中。
用户还有一个步骤--从服务器检索另一个挑战，并使用 navigator.credentials.get API 来签署挑战。我们将签名后的挑战书发回服务器，服务器会验证挑战书，如果签名通过，就会登录我们。
当然，每一步还有很多其他的步骤。但这通常就是我们使用 WebAuthn 或通行密钥登录网站的方式。
## 最基本和最重要的部分
通行密钥在两个不同的阶段使用：证明阶段和断言阶段。
验证阶段也可视为注册阶段。你可以用电子邮件和密码注册一个新网站，但在这种情况下，我们使用的是通行密钥。
断言阶段与注册后登录网站的方式类似。
## 鉴证
![/2023-09-06/attestation.webp](https://oss-blog-static.oss-cn-beijing.aliyuncs.com/2023-09-06/attestation.webp)
navigator.credentials.create API 是我们验证阶段的重点。我们在系统中注册为新用户，需要生成一个新的公钥对。不过，我们需要指定要生成哪种密钥对。这意味着我们需要为 navigator.credentials.create 提供选项。
````
// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialCreationOptions = {
  challenge: safeEncode(challenge),
  rp: {
    id: window.location.host,
    name: document.title,
  },
  user: {
    id: new TextEncoder().encode(crypto.randomUUID()), // Why not make it random?
    name: 'Your username',
    displayName: 'Display name in browser',
  },
  pubKeyCredParams: [
    {
      type: 'public-key',
      alg: -7, // ES256
    },
    {
      type: 'public-key',
      alg: -256, // RS256
    },
  ],
  authenticatorSelection: {
    userVerification: 'preferred', // Do you want to use biometrics or a pin?
    residentKey: 'required', // Create a resident key e.g. passkey
  },
  attestation: 'indirect', // indirect, direct, or none
  timeout: 60_000,
};
````

````
const pubKeyCredential: PublicKeyCredential = await navigator.credentials.create({
  publicKey
});
const {
  id // the key id a.k.a. kid
} = pubKeyCredential;
const pubKey = pubKeyCredential.response.getPublicKey();
const { clientDataJSON, attestationObject } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for registration
````
我们将获得 PublicKeyCredential，其中包含创建后返回的 AuthenticatorAttestationResponse。凭证上有生成的配对密钥的 ID。
该响应提供了一些有用的信息。首先，我们的公钥就在这个响应中，我们需要将其发送到服务器进行存储。其次，我们还获得了 clientDataJSON 属性，我们可以对其进行解码，并从中获得密钥的类型、挑战和来源。
对于验证，我们希望在服务器上验证类型、挑战和来源，并存储带有标识符（如 kid）的公钥。如果需要，我们还可以选择存储 attestationObject。另一个需要存储的有用属性是 COSE 算法，该算法在上面的公钥凭据创建选项（PublicKeyCredentialCreationOptions）中用 alg： -7或alg： -256，以便在断言阶段轻松验证任何已签名的挑战。
navigator.credentials.get API 将是断言阶段的重点。从概念上讲，这将是用户注册后登录网络应用程序的地方。
![/2023-09-06/assertion.webp](https://oss-blog-static.oss-cn-beijing.aliyuncs.com/2023-09-06/assertion.webp)

````
// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialRequestOptions = {
  challenge: new TextEncoder().encode(challenge),
  rpId: window.location.host,
  timeout: 60_000,
};
````
````
const publicKeyCredential: PublicKeyCredential = await navigator.credentials.get({
  publicKey,
  mediation: 'optional',
});
const {
  id // the key id, aka kid
} = pubKeyCredential;
const { clientDataJSON, attestationObject, signature, userHandle } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for verification
````
这次我们将再次获得一个带有 AuthenticatorAssertionResponse 的 PublicKeyCredential。凭据再次包含密钥标识符。
我们还会再次从 clientDataJSON 中获取类型、挑战和来源。签名和身份验证器数据现在都包含在响应中。我们需要这些信息和 clientDataJSON 来验证是否使用了私钥签名。
authenticatorData 包含一些值得跟踪的属性 首先是您使用的源服务器的 SHA256 哈希值，位于前 32 个字节中，用于验证请求是否来自同一源服务器。其次是 signCount，位于第 33 至 37 个字节之间，由验证器生成，应将其与之前的值进行比较，以确保密钥没有任何猫腻。如果是多设备密钥，该值应始终为 0；如果是单设备密钥，该值应随机大于之前的 signCount。
断言登录后，你就可以登录了，通行密钥是一个相当不错的协议，但也有一些注意事项。
## 一些缺点
Passkeys 有很多优点，但在撰写本文时也存在一些问题。首先，Passkeys 还处于早期支持阶段，只允许在 Windows 系统上使用单设备凭证，对 Linux 系统的支持非常少。Passkeys.dev 提供了一个不错的表格，有点像该协议的 Caniuse。
此外，谷歌和苹果的密码键盘平台并不互相通信。如果你想把安卓手机上的认证信息传到 iPhone 上......那你现在就没戏了。这并不是说没有互操作性！你可以用手机作为验证器登录电脑。不过，如果能将其内置到操作系统中并进行同步，而不是锁定在供应商层面，那就更简单了。
## 未来发展趋势
未来的通行密钥协议是什么样的？看起来还不错！一旦它获得更多操作系统的支持，使用率应该会上升，你会看到它在野外被越来越多地使用。一些密码管理器甚至会首先支持它们。Passkeys: What the Heck and Why?
密码钥匙绝不仅仅支持网络。安卓和 iOS 都将支持本地密码匙，将其视为一等公民。虽然这一切还处于早期阶段，但我们希望看到它被越来越多地提及。
毕竟，我们消除了对密码的需求，从而使世界变得更加安全！
## 一些资源
如果你想了解更多关于 Passkeys 的信息，这里有更多资源，还有我为这篇文章准备的资源库和演示：
[实时演示](https://passkeys.neal.codes/) (表单未收集实际信息)
[Demo GitHub Repository](https://github.com/nealfennimore/passkeys)
[YubiKey Documentation](https://developers.yubico.com/Passkeys/)
[Passkeys.dev](https://passkeys.dev/)
[Passkeys.io](https://www.passkeys.io/)
[Webauthn.io](https://webauthn.io/)

> - 原文地址：https://css-tricks.com/passkeys-what-the-heck-and-why/
- 原文标题：Passkeys: What the Heck and Why?
- 原文作者：Neal Fennimore


上网体验最差的环节，肯定是密码，互联网发展了20多年，所有体验的环节都有巨大改善，只有密码除外，在身份验证环节，目前采用的还是20年前的用法，但让人无奈的是，即使如此麻烦，依然不能杜绝密码被盗、被破解、被钓鱼的风险。
多年来，业界一直努力，试图设计出一套密码的替代方案。近两年终于有了突破，各大公司达成一致，设计出了一套密码的替代方案：密钥登录（Passkey），它将作为一种开放标准，由希望使身份验证更安全、更可用的公司联盟开发。