设备绑定会话凭据 (DBSC)

设备绑定的会话凭据 (DBSC) 会添加一层硬件支持的安全机制来缓解此风险，确保会话绑定到特定设备。

Daniel Rubery
Daniel Rubery
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 规范。