设备绑定会话凭据 (DBSC)

设备绑定会话凭据 (DBSC) 通过添加硬件支持的会话安全性来增强身份验证。

Daniel Rubery
Daniel Rubery
José Luis Zapata
José Luis Zapata

简介

许多网站依赖于长效 Cookie 进行用户身份验证，但这些 Cookie 容易遭到会话盗用。设备绑定会话凭据 (DBSC) 会添加一层由硬件支持的安全机制来降低此风险，确保会话绑定到特定设备。

本指南面向在 Web 应用中维护身份验证流程的开发者。其中介绍了 DBSC 的运作方式以及如何将其集成到您的网站中。

DBSC 的运作方式

概括来讲，DBSC 引入了与用户设备关联的加密密钥对。Chrome 会在登录期间生成此密钥对，并将私钥存储在安全硬件（例如可信平台模块 [TPM]）中（如果有）。会话使用短期有效的 Cookie。当其中一个 Cookie 过期时，Chrome 会先证明自己拥有私钥，然后再刷新这些 Cookie。此过程会将会话连续性与原始设备相关联。

如果用户的设备不支持安全密钥存储，DBSC 会顺利回退到标准行为，而不会中断身份验证流程。

实现概览

如需将 DBSC 集成到您的应用中，您需要进行以下更改：

  • 修改登录流程以添加 Sec-Session-Registration 标头。
  • 添加一个会话注册端点，该端点：
    • 将公钥与用户的会话相关联。
    • 提供会话配置。
    • 过渡到短时有效的 Cookie。
  • 添加了刷新端点，用于处理 Cookie 续期和密钥占有情况验证。

大多数现有端点无需进行任何更改。DBSC 旨在增强现有功能，而不会造成干扰。

如果缺少必需的短时有效 Cookie 或 Cookie 已过期，Chrome 会暂停请求并尝��刷新 Cookie。这样，您的应用就可以继续使用常规的会话 Cookie 检查来确认用户是否已登录。由于这与典型的身份验证流程相符，因此只需对登录逻辑进行最少的更改，即可使用 DBSC。

实现步骤

本部分将详细介绍对身份验证系统进行的必要更改，包括如何修改登录流程、处理会话注册以及管理短时有效的 Cookie 刷新。每个步骤都旨在与现有基础架构顺畅集成。

实现步骤遵循已登录用户在 DBSC 处于活动状态时会经历的常见流程：登录时注册，然后定期刷新短时有效的 Cookie。您可以根据应用的会话敏感性级别，独立测试和实现每个步骤。

显示 DBSC 流程的示意图

1. 修改登录流程

用户登录后，使用长效 Cookie 和 Sec-Session-Registration 标头进行响应。例如：

成功注册会话后，系统会返回以下 HTTP 响应标头：

HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

如果设备支持安全密钥存储，Chrome 会使用 JSON Web 令牌 (JWT) 中的公钥与 /StartSession 端点联系。

在此示例中，auth_cookie 表示您的会话令牌。您可以随意为此 Cookie 命名，只要其与会话配置中的 name 字段相匹配，并且在整个应用中一致使用即可。

2. 实现会话注册端点

在 /StartSession 中，您的服务器应：

  • 将收到的公钥与用户的会话相关联。
  • 使用会话配置进行响应。
  • 将长期有效的 Cookie 替换为短期有效的 Cookie。

在以下示例中，短时有效的 Cookie 配置为在 10 分钟后过期：

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. 实现刷新端点

短时有效的 Cookie 过期后，Chrome 会发起刷新流程，以证明自己拥有私钥。此过程涉及 Chrome 和服务器的协调操作：

  1. Chrome 会将用户的请求推迟到您的应用，并向 /RefreshEndpoint 发送刷新请求：

    POST /RefreshEndpoint HTTP/1.1
Sec-Session-Id: session_id

  2. 您的服务器会使用质询进行响应：

    HTTP/1.1 401 Unauthorized
Sec-Session-Challenge: "challenge_value"

  3. Chrome 使用存储的私钥对质询进行签名，并重试请求：

    POST /RefreshEndpoint HTTP/1.1
Sec-Session-Id: session_id
Sec-Session-Response: <JWT proof>

  4. 您的服务器会验证已签名的证明并发出刷新的短时有效 Cookie：

    HTTP/1.1 200 OK

Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax

  5. Chrome 会收到刷新的 Cookie，并恢复原始的延迟请求。

备选集成模式

为了提高弹性，网站可以在短时性 Cookie 旁边添加第二个非 DBSC Cookie。此长效 Cookie 仅用于发出新的短效令牌，有助于区分真正未经身份验证的请求和临时 DBSC 失败。

  • 即使 DBSC 失败，长效 Cookie 也会保留。
  • 系统会使用 DBSC 刷新短时有效的 Cookie，敏感操作需要使用此 Cookie。

这种模式可让网站更好地控制如何处理极端情况。

注意事项和后备行为

在以下情况下，Chrome 可能会跳过 DBSC 操作，并发送不包含 DBSC 管理的短时有效 Cookie 的请求：

  • 由于网络错误或服务器问题，无法访问刷新端点。
  • TPM 处于忙碌状态或遇到签名错误。由于 TPM 在系统进程中共享，过多的刷新可能会超出其速率限制。
  • DBSC 管理的短时性 Cookie 是第三方 Cookie，而用户已在其浏览器设置中屏蔽第三方 Cookie。

在这些情况下，如果仍存在长期有效的 Cookie，Chrome 会回退使用该 Cookie。只有当您的实现同时包含长时有效和短时有效的 Cookie 时，此回退才有效。否则，Chrome 会在不使用 Cookie 的情况下发送请求。

摘要

设备绑定会话凭据可最大限度地减少对应用的更改，从而提高会话安全性。它们通过将会话绑定到特定设备，提供更强的会话盗用防范措施。大多数用户无需受到任何干扰即可受益，并且 DBSC 会在不受支持的硬件上进行正常回退。

如需了解详情，请参阅 DBSC 规范。