设备绑定会话凭据 (DBSC)

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

Daniel Rubery
Daniel Rubery
José Luis Zapata

简介

许多网站都依赖长期有效的 Cookie 来进行用户身份验证，但这些 Cookie 容易受到会话劫持的攻击。设备绑定会话凭证 (DBSC) 可添加一层基于硬件的安全保护来降低此风险，确保会话绑定到特定设备。

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

DBSC 的运作方式

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

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

实施概览

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

  • 修改登录流程以包含 Secure-Session-Registration 标头。
  • 添加会话注册端点，该端点：
    • 将公钥与用户会话相关联。
    • 提供会话配置。
    • 过渡到短期 Cookie。
  • 添加刷新端点以处理 Cookie 续订和密钥持有权验证。

您的大部分现有端点都不需要进行任何更改。DBSC 旨在实现增量式且不中断的备份。

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

实现步骤

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

实现步骤遵循已登录用户在 DBSC 处于有效状态时会体验到的常见流程：在登录时进行注册，然后定期刷新短期 Cookie。您可以根据应用的会话敏感度，单独测试和实现每个步骤。

展示 DBSC 流程的示意图

1. 修改登录流程

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

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

HTTP/1.1 200 OK
Secure-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-Secure-Session-Id: session_id

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

    HTTP/1.1 403 Forbidden
Secure-Session-Challenge: "challenge_value"

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

    POST /RefreshEndpoint HTTP/1.1
Sec-Secure-Session-Id: session_id
Secure-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 也会保留。
  • 短期有效的 Cookie 使用 DBSC 进行刷新，并且是敏感操作所必需的。

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

注意事项和回退行为

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

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

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

摘要

设备绑定会话凭证可在对应用进行极少更改的情况下提升会话安全性。它们通过将会话与特定设备相关联，提供更强的保护来防范会话劫持。大多数用户都能受益，而不会遇到任何中断，并且 DBSC 会在不受支持的硬件上正常回退。

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