深入了解设备绑定会话凭据 (DBSC)

企业 Passkey 白皮书. 面向 passkey 项目的实用指南、推广模式和 KPI。

获取白皮书

浏览器支持状态

图例： ✅ 全面推出 (GA) | 🚧 已宣布 / 开发中 | ⏸️ 试用结束 | 🔄 评估/监控中 | ❌ 尚未提供

注意： 截至 Chrome 146（2026 年 4 月），DBSC 结合 TPM 在 Windows 上已全面推出 (GA)。通过安全隔区的 macOS 支持即将推出。Google 声明的路线图还包含基于软件的密钥，以将保护扩展到没有专用安全硬件的设备。

核心优势：DBSC 与现有模型对比

万维网的架构基于无状态原则。最初设计 HTTP 时，它并不在请求之间保留有关用户的信息。为了解决这个问题，“Cookie”应运而生——它是一小段从网站发送并存储在用户计算机上的数据，在每次后续请求中发回给网站。几十年来，这种机制一直作为会话管理的基石。当用户登录时，服务器验证其凭据并颁发一个 Cookie。这个 Cookie 充当了“承载令牌”。在现实世界中，不记名票据是一种赋予持有人其所代表的权利或资产的文件；如果您持有债券，您就拥有该债券。类似地，在 HTTP 的数字世界中，如果您持有 Cookie，您就是该用户。

这种持有能力既是 Web 最大的实用性，也是其最深刻的漏洞。整个会话的安全性——并由此延伸出用户的身份、数据和金融资产的安全性——完全取决于该 Cookie 字符串的保密性。如果恶意行为者复制了该字符串，他们就可以在世界任何地方的任何设备上冒充该用户，完全绕过最初的身份验证检查。这个特定的漏洞催生了工业级规模的“Cookie 盗窃”和“会话劫持”地下经济。

随着业界通过采用 FIDO 标准和通行密钥成功地强化了身份验证的“前门”，攻击者正在将重点转移到“后门”：活跃会话。网络钓鱼密码变得越来越困难，但窃取会话 Cookie 仍然非常有效。针对这种不断升级的威胁，业界的对策是 设备绑定会话凭据 (DBSC)。

DBSC 代表了维持 Web 会话范式的转变。它建议从简单的承载令牌模型转向会话被密码学地绑定到设备的模型。随着 Chrome 146 (2026 年 4 月) 在 Windows 上全面推出 DBSC，该标准已经从实验性质转变为 Web 团队如今可以部署的生产功能。Chrome 在 Windows 上使用 TPM，并即将在 macOS 上推出对安全隔区的支持；该规范本身对密钥存储方式不作限制，只要求它“对所描述的威胁具有强健性”。这极大地降低了被盗 Cookie 的价值。没有绑定的密钥，它们无法从另一台设备刷新。

本文提供了对 DBSC 的详尽分析，专为安全架构师、产品经理和开发人员设计。它探讨了技术架构、“无感安全”的商业影响、与共享信号 (CAEP/RISC) 等新兴标准的关系，以及组织如何利用 Corbado 等平台为这一未来做好准备。

本文解答的核心问题

1. 为什么当前的会话管理未能防范账户接管？
2. DBSC 与现有的“安全”Cookie 和 HttpOnly 标志有何不同？
3. DBSC 和通行密钥如何协同工作以增强抗网络钓鱼能力？
4. 令牌绑定为何失败，为什么 DBSC 能在它失败的地方取得成功？
5. 对产品经理而言，其商业影响和 ROI 是什么？
6. 目前哪些浏览器和操作系统支持 DBSC？
7. 组织如何在不从头构建的情况下实施 DBSC？
8. DBSC、DPoP 和 OAuth 2.0 之间的关系是什么？
9. DBSC 如何与共享信号 (CAEP/RISC) 集成以实现实时威胁响应？

要驾驭这个新标准的复杂性，我们必须首先了解当前会话管理的根本问题，以及 DBSC 是如何提供解决方案的。这些领域中的每一个都代表了一个 DBSC 所要解决的关键漏洞或限制。

当前会话管理的根本失败在于信任的“可移植性”。当服务器签发一个会话 Cookie 时，它实际上是签发了一本适用于任何持有者的护照。虽然浏览器实施了诸如 HttpOnly 和 Secure 标志（防止 JavaScript 访问并确保通过 HTTPS 传输）等防御措施，但这些防御措施只能防范特定的提取向量，如跨站脚本攻击 (XSS) 或网络嗅探。它们对运行在主机设备上的恶意软件束手无策。“信息窃取程序”是一种专门设计的恶意软件，用于在磁盘上定位浏览器的 Cookie 存储文件，将其解密（通常使用用户自己的操作系统级别的凭据），并将内容泄露给命令与控制服务器。一旦攻击者获得了 Cookie，他们就可以执行传递 Cookie 攻击，将窃取的令牌注入自己的浏览器以劫持会话。看到有效 Cookie 的服务器会假定该请求是合法的。

DBSC 在会话维护循环本身中引入了第二因素身份验证。与标准安全 Cookie（这是一个静态的秘密）不同，DBSC 会话包含一个生命周期较短的承载令牌和加密的拥有证明。浏览器生成一个安全存储在设备上的公私钥对。服务器将会话绑定到公钥。定期地，浏览器必须通过签署来自服务器的挑战来证明它仍持有私钥。规范要求密钥存储“对所描述的威胁具有强健性”。Chrome 在可用时使用 Windows 上的 TPM。如果攻击者从另一台设备窃取了 Cookie，他们无法刷新它，因为他们无法生成必需的密码学签名。“承载”方面被最小化到一个非常短的窗口期，而“绑定”方面则提供了长期的连续性。

通行密钥和 DBSC 是互补的技术，用于保护用户生命周期的不同阶段。通行密钥 (FIDO2) 解决了_身份验证_问题——在没有密码的情况下证明身份以启动会话，从而消除了凭据钓鱼。DBSC 解决了_身份验证后_问题——使通过 Cookie 盗窃进行的会话劫持变得困难得多。FIDO 联盟将 DBSC 定位为提高防范会话劫持标准的补充技术。它们共同减少了登录和会话生命周期中的攻击面——尽管 DBSC 无法防范持续访问设备的恶意软件或同一设备上的实时中间人浏览器攻击。

通行密钥和 DBSC 如何协同工作

DBSC 并非解决此问题的首次尝试。“令牌绑定”是以前的一项标准，试图将 Cookie 绑定到基础 TLS（传输层安全）连接。虽然在密码学上是合理的，但令牌绑定由于严重依赖 TLS 层而未能获得采用。在现代 Web 中，TLS 连接通常在负载均衡器、CDN 或反向代理处终止，而应用程序逻辑位于它们后方的服务器上。将令牌绑定信息通过这些复杂的网络层传播被证明是极其困难的。DBSC 吸取了这一教训，它完全在应用层 (HTTP) 运行。它不依赖于底层网络连接，使其与现有的负载均衡器、代理和云基础设施兼容。

对产品领导者而言，DBSC 提供了一个在提高安全性的同时改善用户体验 (UX) 的机会。传统上，高安全性意味着较短的会话超时时间，迫使用户频繁登录（阻力）。通过将会话绑定到设备，远程 Cookie 盗窃的风险大大降低。企业可以考虑更长的会话持续时间，因为他们知道被盗的 Cookie 无法从其他设备上刷新。然而，DBSC 并不能防范设备失窃、设备上的持久性恶意软件或恶意用户的滥用，因此会话生存期策略仍应反映这些残余风险。

要理解 DBSC 背后的紧迫性，就必须认清现代威胁形势的复杂性。窃取会话 Cookie 已从一种小众的黑客手段升级为一个可扩展的自动化产业。

graph TD
    A[用户下载<br/>恶意软件] -->|执行| B[信息窃取程序在<br/>设备上激活]
    B --> C[定位浏览器数据]
    C --> D[Chrome/Edge/Firefox<br/>Cookie 存储]
    C --> E[密码数据库]
    C --> F[加密钱包]

    D --> G[使用<br/>OS凭据解密]
    E --> G
    F --> G

    G --> H[创建包含<br/>窃取数据的日志文件]
    H --> I[泄露给 C2 服务器]
    I --> J[暗网市场]

    J --> K[攻击者购买日志]
    K --> L[将 Cookie 导入<br/>自己的浏览器]
    L --> M[绕过 MFA]
    M --> N[账户接管<br/>完成]

    style A fill:#ff6b6b,color:#fff
    style B fill:#ff6b6b,color:#fff
    style N fill:#ff6b6b,color:#fff
    style J fill:#495057,color:#fff
    style M fill:#ffd43b,color:#000

恶意软件即服务 (MaaS) 降低了网络犯罪分子的准入门槛。像 RedLine、Raccoon、Vidar 和 Taurus 等“信息窃取程序”是市面上可以买到的恶意软件变种，它们的主要目标只有一个：从 Web 浏览器中泄露数据。这些窃取程序通过钓鱼邮件、破解软件或恶意广告分发。一旦安装，它们就会瞄准 Chrome、Edge 和 Firefox 等浏览器存储其数据的特定文件路径。

• 目标： Cookie 数据库（通常是 SQLite 文件）和登录数据数据库（保存的密码）。
• 机制： 浏览器使用与用户操作系统登录信息相关联的数据保护 API（Windows 上的 DPAPI）来加密这些数据库。由于恶意软件是以_用户身份_运行的，因此它可以轻松请求解密这些文件。
• 输出： 恶意软件生成一个“日志”——一个包含解密后的 Cookie、密码、系统信息以及（有时）加密钱包密钥的 zip 文件。

这些日志被汇集并在暗网市场（如被摧毁前的 Genesis Market 和 Russian Market）上出售。买家可以搜索包含针对特定高价值目标活动 Cookie 的日志：“Salesforce”、“Gmail”、“Bank of America”或“AWS Console”。

绕过防御： Cookie 日志的价值在于其绕过多因素身份验证 (MFA) 的能力。大多数 MFA 挑战（短信、TOTP、推送）仅在_登录_事件期间发生。一旦建立了会话并颁发了 Cookie，服务器就会认为用户是受信任的。导入有效会话 Cookie 的攻击者会直接滑过 MFA 关卡，在服务器看来，这就像是用户返回到了一个活动的标签页。

云生产力套件是首要目标。针对 Google Workspace 或 Microsoft Entra ID（前身为 Azure AD）帐户被盗的会话 Cookie，可让攻击者访问公司电子邮件、文档和内部系统。Google 自己的威胁情报报告称，作为访问 Google 帐户的主要载体，Cookie 盗窃行为激增，明确指出这就是他们投资 DBSC 的驱动因素。他们注意到，随着他们强制启用两步验证 (2SV) 和通行密钥，攻击者只是把策略从凭据网络钓鱼（2SV / 通行密钥可防范）转移到了 Cookie 盗窃（2SV / 通行密钥通常无法防范）。

从历史上看，风险引擎试图通过分析设备指纹、查看 User-Agent 字符串、屏幕分辨率、安装的字体和 IP 地址来检测会话窃取。如果一个会话 Cookie 突然从一个具有稍微不同的 Canvas 指纹的新 IP 出现，服务器可能会使其失效。问题在于： 浏览器中的隐私保护倡议（如 Safari 的智能防跟踪和 Chrome 的隐私沙盒）正在积极降低这些指纹的熵值，以阻止广告跟踪。这使得用于安全的“良好”指纹识别变得越来越困难。此外，攻击者现在使用“反检测浏览器”，使他们能够完美地伪造这些指纹以匹配受害者的个人资料，从而导致启发式检测失效。DBSC 用确定性的密码学证明取代了这种概率性的猜测游戏。

设备绑定会话凭据 (DBSC) 引入了一个标准化的 API 和协议，用于创建绑定到客户端设备上的密钥的会话。规范要求密钥存储“对所描述的威胁具有强健性”，但对实现方式不作限制。Chrome 在可用时在 Windows 上使用 TPM。本节详细介绍了 W3C 工作草案和 Chrome 文档中定义的机制。

DBSC 生命周期允许从标准会话无缝过渡到绑定会话，确保向后兼容性和渐进式增强。

sequenceDiagram
    participant User as 用户
    participant Browser as 浏览器
    participant HSM as HSM (TPM/安全隔区)
    participant Server as 服务器

    Note over User,Server: 第 1 阶段：身份验证与绑定
    User->>Browser: 使用凭据/通行密钥登录
    Browser->>Server: 身份验证请求
    Server->>Browser: 成功 + DBSC 注册标头
    Browser->>HSM: 生成密钥对
    HSM->>Browser: 公钥/私钥（私钥不可导出）
    Browser->>Server: 注册公钥（已签名的 JWT）
    Server->>Server: 将会话绑定到公钥
    Server->>Browser: 短期 Cookie（5 分钟）

    Note over User,Server: 第 2 阶段：正常使用
    loop 每 5 分钟内的请求
        Browser->>Server: 带 Cookie 的请求
        Server->>Browser: 响应
    end

    Note over User,Server: 第 3 阶段：刷新（过期后）
    Browser->>Server: 带过期 Cookie 的请求
    Server->>Browser: 401 + 挑战 Nonce
    Browser->>HSM: 签署挑战
    HSM->>Browser: 签名
    Browser->>Server: 签名证明
    Server->>Server: 用存储的公钥验证
    Server->>Browser: 新的短期 Cookie
    Browser->>Server: 重试原始请求
    Server->>Browser: 成功响应

绑定过程在用户使用标准方法（密码、通行密钥等）成功进行身份验证后立即开始。

1. 服务器信号： 成功登录后，服务器像往常一样设置会话 Cookie，但会添加一个指示支持 DBSC 的特定标头。

   HTTP
   HTTP/1.1 200 OK
   Set-Cookie: session_id=xyz123...; Secure; HttpOnly; SameSite=Strict
   Secure-Session-Registration: (ES256 RS256); path="/auth/dbsc/register"
   

   • Secure-Session-Registration 标头告诉浏览器：“我支持算法 ES256 和 RS256。请在端点 /auth/dbsc/register 注册绑定的会话。”

2. 密钥生成： 浏览器解析该标头。它生成一个新的非对称密钥对（例如，椭圆曲线 P-256），安全地存储在设备上。

   • 实现注意事项： Chrome 在可用时使用 Windows 上的 TPM；该规范对存储机制不作限制，只要求其“对所描述的威胁具有强健性”。
   • 隐私范围： 该密钥的作用域限于该 Web 来源（例如，bank.com）。浏览器确保该密钥永远不会被用于 retailer.com，以防跨站点跟踪。

3. 注册请求： 浏览器向指定的注册路径发送请求。该请求在由私钥签名的 JSON Web 令牌 (JWT) 中包含新生成的公钥（自签名证明）。

   HTTP
   POST /auth/dbsc/register HTTP/1.1
   Content-Type: application/jwt
   
   \<JWT 标头\>.\<包含公钥的 JWT 载荷\>.\<签名\>
   

4. 会话绑定： 服务器验证该签名，确保公钥功能正常。然后，它会更新数据库，将用户的会话（session_id=xyz123）与特定的公钥相关联。从此开始，该会话将被“绑定”。

为了在安全性与性能之间取得平衡（安全密钥操作可能会增加延迟），DBSC 采用双令牌系统。

1. 签发： 服务器签发一个_新_的短期 Cookie（例如，有效期 5 分钟）。我们将其称为 access_token。
2. 使用： 浏览器在所有普通请求（提取图像、API 调用、页面导航）中使用该 access_token。只要该 Cookie 有效，就不会执行任何加密操作。这样可以确保浏览速度较快。
3. 过期： 5 分钟后，access_token 失效。

这是安全机制的核心部分。当短期 Cookie 过期后，另一台设备上的攻击者将被拦截在系统外，而具有绑定密钥权限的合法用户可以继续访问。

1. 检测： 浏览器尝试发起请求。它注意到该 Cookie 已过期（或者服务器返回 401 响应或特定 Secure-Session-Challenge 标头）。
2. 拦截： 浏览器_暂停_该网络请求。它不会向用户显示错误信息。
3. 刷新请求： 浏览器自动调用会话配置中定义的刷新端点。
   • 服务器发送加密挑战（Nonce）。
   • 浏览器使用绑定的密钥对此挑战进行签名。
   • 该签名证明拥有私钥。
4. 提交： 浏览器将签名后的挑战发送回服务器。

   HTTP
   POST /auth/dbsc/refresh HTTP/1.1
   Sec-Secure-Session-Id: \<Session ID\>
   Secure-Session-Response: \<挑战的 JWT 签名\>
   

5. 验证： 服务器使用存储的公钥对签名进行验证。
   • 如果有效： 服务器确信该请求源自启动会话的同一台物理设备。它会签发一个_新_的短期 access_token（有效期再延长 5 分钟）。
   • 如果无效： 拒绝该请求。终止会话。
6. 恢复： 浏览器获得新 Cookie 后透明地重试最初暂停的请求。用户在体验上不受任何干扰。

graph LR
    subgraph "受害者设备"
        A[启用 DBSC 的<br/>用户会话]
        B[HSM/TPM<br/>私钥]
        C[Cookie +<br/>Session ID]
        A --> B
        A --> C
        B -.->|不可导出| X[无法提取<br/>私钥]
    end

    subgraph "攻击场景"
        D[RedLine 窃取程序<br/>感染设备]
        D --> E[窃取 Cookie<br/>和 Session ID]
        E --> F[导出给<br/>攻击者]
    end

    subgraph "攻击者设备"
        G[导入被盗<br/>Cookie]
        H[尝试<br/>使用会话]
        I[服务器请求<br/>DBSC 刷新]
        J[无法签署<br/>挑战]
        K[会话被拒绝]

        G --> H
        H --> I
        I --> J
        J --> K
    end

    C -.->|被盗| E
    F --> G

    style D fill:#ff6b6b,color:#fff
    style K fill:#51cf66,color:#fff
    style B fill:#4c6ef5,color:#fff
    style X fill:#51cf66,color:#fff
    style J fill:#ff6b6b,color:#fff

假设一个攻击者利用 RedLine 窃取程序感染了用户的 PC。他们窃取了 access_token 和 session_id。他们将这些数据导入自己的浏览器。

• 场景 A（5 分钟内）： 攻击者可能仅几分钟的时间具有访问权限，直至短期令牌失效。
• 场景 B（过期后）： 攻击者的浏览器（在另一台设备上）尝试使用该令牌。服务器拒绝使用并要求刷新。攻击者的浏览器看到 DBSC 标头，但无法执行刷新，因为它没有绑定的私钥。攻击失败。

隐私是 DBSC 的核心设计目标。W3C 规范明确禁止使用可能跨网站跟踪用户的全局标识符。

• 单源密钥： 浏览器为每个站点生成一个独有的密钥对。google.com 看到的是密钥 A；amazon.com 看到的是密钥 B。两者之间没有关联。
• 用户清除数据： 若用户清除了 Cookie 或网站数据，浏览器也会同时删除关联的 DBSC 密钥。这能确保 DBSC 不能作为重新建立已删除身份信息的“超级 Cookie”被滥用。

部署 DBSC 需要服务器维护关于公钥的状态。

• 数据库模式： 会话表必须更新，以在 user_id 和 session_expiry 旁边存储 public_key 和 last_challenge。
• 性能： 刷新操作涉及密码学验证（例如，验证 ECDSA 签名）。虽然速度很快，但比验证简单的字符串更耗 CPU。但是，因为刷新只是每隔几分钟（而不是每次请求）才发生，所以开销可以忽略不计。

除了技术规范之外，DBSC 对商业战略、产品路线图和合规状态也具有重要意义。

安全举措经常被视为成本中心或阻力生成器。DBSC 扭转了这种说法。下图展示了设备绑定如何产生一连串的商业收益：

• 欺诈减少： 通过消除账户接管 (ATO) 的主要媒介，企业可以在欺诈损失方面节省数百万美元。
• 支持成本： 账户恢复成本很高。从一开始就防止黑客攻击直接减轻了这种运营负担。
• 转化率优化： 在电子商务中，每一次登录提示都是潜在的流失点。DBSC 允许采取积极的“保持登录状态”策略，实现无需密码提示的即时结账。

欧洲《通用数据保护条例》(GDPR) 等监管框架要求组织实施“适当的技术和组织措施”来确保安全。

• 可辩护的安全： 随着 DBSC 成为标准，它可能会被解释为会话管理的“最新技术水平”。发生违规事件时，证明实施了 DBSC 可以成为防范疏忽指控的有力辩护。
• 银行标准 (PSD2)： 支付服务指令 2 要求“强客户身份验证”(SCA)。虽然 SCA 侧重于登录，但会话与设备的动态链接完全符合指令将身份验证与特定金额和收款人绑定的目标。

FIDO 联盟白皮书强调了“保证等级”的概念。

• 中等保证： 使用同步的通行密钥（如 iCloud 钥匙串中的密钥）。适用于消费类应用程序，可恢复，易于使用。
• 高保证： 要求设备绑定的密钥。这是 DBSC 闪耀的地方。对于企业资源（HR 门户网站、代码存储库）或高价值银行服务，组织可能会强制执行一种策略，即_仅_允许从绑定到特定管理设备的会话中进行访问。DBSC 为这种策略提供了技术执行机制。

为了充分评估 DBSC 的价值，我们必须将其与过去尝试解决相似技术的其他方案进行比较。

graph RL
    subgraph "传统 Cookie"
        TC1[仅承载令牌]
        TC2[容易被窃取]
        TC3[长会话 = 高风险]
        TC1 --> TC2
        TC2 --> TC3
    end

    subgraph "令牌绑定"
        TB1[TLS 层绑定]
        TB2[❌ 失败：基础设施复杂]
        TB3[在负载均衡器处中断]
        TB1 --> TB2
        TB2 --> TB3
    end

    subgraph "DPoP"
        DP1[OAuth 令牌绑定]
        DP2[✅ API 保护]
        DP3[不适用于浏览器会话]
        DP1 --> DP2
        DP2 --> DP3
    end

    subgraph "DBSC"
        D1[HTTP 层绑定]
        D2[✅ 硬件密钥保护]
        D3[✅ 与 CDN/LB 协作]
        D4[✅ 浏览器会话]
        D1 --> D2
        D2 --> D3
        D3 --> D4
    end

    style TC2 fill:#ff6b6b,color:#fff
    style TB2 fill:#ff6b6b,color:#fff
    style D2 fill:#51cf66,color:#fff
    style D3 fill:#51cf66,color:#fff
    style D4 fill:#51cf66,color:#fff
    style DP2 fill:#51cf66,color:#fff

如前所述，令牌绑定试图将会话绑定到 TLS 层。

• 令牌绑定： 需客户端、服务器_及_这二者间的任何一跳（负载均衡器、TLS 终止器）给予支持。一旦某个连接终止且重新加密，它就会中断。
• DBSC： 在 HTTP 应用层运行。它能够作为标准的标头 / Cookie 透明地穿过负载均衡器。部署于现代的云架构（AWS / GCP / Azure）要简单得多，在此种架构内 TLS 常常由云提供商的边缘网络负责处置。

DPoP (RFC 9449) 是“发件人约束”OAuth 令牌的标准。它将访问令牌_和_刷新令牌都绑定到公钥——这一点很关键，因为刷新令牌本身就是寿命很长的持有者凭证。每个 API 请求包含一个 DPoP 证明：一个带有 HTTP 方法、URL、时间戳和唯一标识符的签名 JWT。高保证规范，如 FAPI 2.0 规定要求发件人受限令牌；当 mTLS 不可用时，DPoP 是推荐的方法。

关键区别： DPoP 密钥位于应用程序上下文中。最佳实践是使用 OS API 进行不可提取的存储，但这没有被强制执行——许多实现将密钥保存在 JavaScript 可访问的内存中。如果攻击者可以执行任意代码（XSS、恶意软件），他们就可以访问 DPoP 密钥或按需生成证明。DPoP 阻止了_不同客户端之间_的令牌重放，但不能保护已受损的浏览器上下文。

DBSC 将拥有证明移至浏览器和硬件中。私钥存在于 TPM 或安全隔区中，JavaScript 无法读取或导出。浏览器在不将密钥暴露给应用程序代码的情况下处理协议并生成签名。即使 Web 应用程序完全受到损害，攻击者也无法在另一台机器上为窃取的 Cookie 伪造新的证明。

协同作用： 正如 FIDO 联盟指出的那样，通行密钥在登录时消除了网络钓鱼，而 DBSC/DPoP 在认证后保护了令牌。现代架构两者结合：将 DPoP 用于 OAuth API（尤其在受监管的开放银行领域），将 DBSC 用于浏览器会话。它们携手合力封堵整个会话生命周期中的“直接迁移”攻击媒介。

如果只单纯缩短 Cookie 的有效期（例如缩短至 15 分钟），虽能提升安全性，但会严重损害用户体验。用户会被迫不停登录。DBSC 则能让兼具 5 分钟 Cookie 的_实际_安全性和 30 天 Cookie 的_用户体验_成为可能。

%%{init: {
  "theme": "default",
  "themeVariables": {
    "actorBkg": "#ffffff",
    "actorBorder": "#000000",
    "noteBkgColor": "#f1f3f5",
    "noteTextColor": "#000000",
    "activationBkgColor": "#e0e0e0",
    "actorColours": {
      "ST": "#ff6b6b",
      "IdP": "#4c6ef5"
    }
  }
}}%%

sequenceDiagram
    participant ST as 安全工具<br/>(CrowdStrike, Defender)
    participant IdP as 身份提供商<br/>(Okta, Google, Azure)
    participant SP1 as 服务提供商 1<br/>(Slack)
    participant SP2 as 服务提供商 2<br/>(Salesforce)
    participant SP3 as 服务提供商 3<br/>(银行应用程序)
    participant Session as 用户会话<br/>(受 DBSC 保护)

    Note over ST,Session: 威胁检测阶段
    ST->>ST: 检测到用户设备上的<br/>恶意软件
    ST->>IdP: RISC 信号：<br/>“设备被攻破”

    Note over IdP,SP3: 信号传播阶段
    IdP->>SP1: CAEP 事件：<br/>“设备被攻破”
    IdP->>SP2: CAEP 事件：<br/>“设备被攻破”
    IdP->>SP3: CAEP 事件：<br/>“设备被攻破”

    Note over SP1,Session: 执行阶段 (带 DBSC)
    Session->>SP1: 下次刷新尝试<br/>(几分钟内)
    SP1-->>Session: x 拒绝签名
    Session->>SP2: 下次刷新尝试
    SP2-->>Session: x 拒绝签名
    Session->>SP3: 下次刷新尝试
    SP3-->>Session: x 拒绝签名

    Note over Session: 可以在下次刷新尝试时终止会话

DBSC 与共享信号框架 (SSF)，特别是连续访问评估配置文件 (CAEP) 和风险管理 (RISC) 结合使用时，其潜力将被放大。注意：SSF/CAEP 是一种新兴的生态系统功能——架构模式已被定义，但跨供应商的广泛部署仍在成熟中。

在旧模型中，如果用户的设备受损，身份提供商 (IdP) 无法告知服务提供商 (SP)_立即_终止会话。SP 不得不等待 Cookie 过期。

设想的 DBSC + CAEP 流程：

1. 触发： 终端安全工具（如 CrowdStrike 或 Microsoft Defender）检测到用户笔记本电脑上的恶意软件。
2. 信号： 安全工具向身份提供商（如 Okta/Google）发送 RISC 信号。
3. 传播： IdP 向连接的应用程序推送 CAEP 事件：“设备已受损”。
4. 执行 (DBSC)： 浏览器下次尝试刷新 DBSC 短期 Cookie 时，服务器会拒绝该签名并终止会话。这种架构模式实现了更快的撤销——实际延迟取决于网站的刷新周期以及它们是否实现了 DBSC 和 SSF。

DBSC 的采用情况取决于各大浏览器供应商。2026 年的前景发生了实质性的转变：Chrome 于 2026 年 4 月将 DBSC 从源试用阶段转移到 Windows 上的全面推出，macOS 紧随其后。其他浏览器仍处于评估阶段。

Google 是 DBSC 的主要推动者，也是率先广泛发布 DBSC 的浏览器。

• 状态（2026 年 4 月）： Chrome 146 针对 Windows 用户全面推出了 DBSC，结束了“源试用”阶段。使用安全隔区的 macOS 支持已宣布将在未来的 Chrome 版本中发布。
• 硬件： Windows 采用 TPM，macOS 将采用安全隔区。Google 已声明，它也在探索基于软件的密钥，以将 DBSC 的保护延伸到没有专属安全硬件的设备。
• 路线图： Google 在其 GA 公告中还发布了下一步路线图：
  • 保护联合身份： 跨源 DBSC 绑定，使得依赖方 (RP) 会话保持绑定到与身份提供商 (IdP) 会话相同的设备密钥，从而在 SSO 中保持完整的信任链。
  • 高级注册： 将 DBSC 会话绑定到已存在的受信任密钥材料（例如 mTLS 证书 或 硬件安全密钥），而不是在登录时生成新密钥。
  • 更广泛的设备支持： 面向没有 TPM / 安全隔区的设备推出基于软件的密钥。
• 运营成效： Google 报告称，在推出期间，受 DBSC 保护的会话的“会话盗窃显著减少”。
• Google 帐户： 另外，Google 早已在由企业策略控制的 Windows 版 Chrome 上部署了类似 DBSC 的针对 Google 帐户 Cookie 的保护。这保护了 Gmail/Workspace 并且现在成为了面向常规网络全面推出 (GA) 的同一系列技术。

微软正积极参与进来。

• 状态： Edge 于 Windows 上展开的 DBSC 源试用已在 2025 年 10 月结束。目前并没有声明替代试用项目或者是全面推出的时间。
• 企业环境： Edge 将“主刷新令牌” (PRT) 架构应用于 Entra / Azure AD SSO ，其在概念层面跟 DBSC 颇为相似。然而，PRT 依旧作为微软特有的机制；暂时还未公布针对第三方站点的与 DBSC Web 标准整合的相关计划。

苹果的立场对于移动端覆盖率至关重要。

• 状态： WebKit 存有一个评估 DBSC 的标准立场议题，并特别指出了关于可用性 / 隐私方面的关切。Safari 的发行说明没有提及 DBSC。当前不存在公开的“正在积极实施”这类声明。
• 隐私至上： 苹果的核心顾虑在于 DBSC 有可能被拿来充作“超级 Cookie”（无法删除的跟踪）。W3C 规范以确保将密钥与网站数据一道清除的做法来应对此项顾虑。
• 参与情况： WebKit 正投身于标准进程，但具体实施状况并不明朗——处于“讨论之中”而非“开发之中”。

Mozilla 有一个标准立场议题在评估 DBSC，同时指出了对于复杂性以及隐私层面的担忧。一旦该标准趋于稳定，Mozilla 目前并没有公开发布致力于实施它的承诺。

鉴于目前生态系统对 DBSC 和通行密钥的支持情况，组织应采用分阶段的方法来实施这些互补技术。以下路线图概述了直接行动和战略规划里程碑：

1. 优先部署通行密钥：从部署通行密钥入手，保障身份验证层的安全。这不但能够即刻防范凭证钓鱼攻击，还是切实从 DBSC 中获取价值的前提条件。

2. 发布 DBSC 注册与刷新端点：随着 Chrome 146 全面推出，实际需着手进行的是后端整合工作：在登录响应处加上 Secure-Session-Registration 标头，并且部署 /dbsc/register 以及一个旨在核实经签名挑战的刷新端点。前端代码则无需改动。

3. 实施采用刷新机制的短期会话：倘若您尚未准备好启用 DBSC，可采用带有刷新机制的短期令牌架构模式。这既能为您后端的 DBSC 部署做好铺垫，又可以在当下提升安全性。

1. 采用混合方法：利用特性检测将 DBSC 部署在可兼容的浏览器上（目前包括 Windows 系统的 Chrome 146+，macOS Secure Enclave 版本紧随其后），并保留备用选项。这不仅最大限度地提高了安全性，同时也没有忽略使用 Safari、Firefox 或是 Edge 的用户群体。

2. 为后续路线图项目做好准备：Google 明确提出包含联合身份（跨源 SSO 绑定）、高级注册（mTLS / 硬件密钥）及用于拓宽设备覆盖的软件级密钥计划。如果您掌管 SSO 或 IdP 层，从此时起就应该着手考量跨源绑定的范畴。

3. 与身份提供商集成：倘若您使用的是 Okta、Auth0 或同类的 IdP 方案，请与他们携手，在其 SDK 体系中提供对 DBSC 的支持。众多提供商参与了先前期的 Origin Trials，而且在 Chrome 实现全员推送后纷纷着手推送相关 DBSC 的兼容能力。

• 从高价值目标入手：优先在管理面板、金融交易和敏感数据访问中应用 DBSC。
• 使用托管解决方案：考虑使用像 Corbado 这样的平台，以处理 DBSC 实施的复杂性和浏览器的兼容性。
• 衡量和迭代：跟踪指标（例如会话劫持尝试、支持工单和用户阻力）以证明投资回报率 (ROI)。
• 准备合规性：记录您的 DBSC 实现情况，因为这可能会成为处理敏感数据的合规性要求。

从头实施 DBSC 是一项繁重的工程。它需要密码学专业知识、对浏览器不一致性的深刻理解，以及强大的服务器端基础架构来管理密钥和挑战。这正是 Corbado 作为赋能者发挥作用的地方。

你不可能建立在一个低保证强度的登录之上来构筑高保证的会话。要是用户采用的是脆弱易破解的密码，那么会话的安全性也仅仅等同于那组脆弱的密码。Corbado 的核心产品（托管式通行密钥）正是为你夯实这最必要的根基。通过引入 Corbado 平台，组织可轻而易举地将通行密钥投放到应用当中，确保这一环节能够稳妥抗御各类网络钓鱼。

Corbado 将运用 DBSC 增强其对于可信设备的感知力。DBSC 产生的信号就像是“数字身份证”，能通过极难伪造的密码学验证手法表明会话究竟源自哪台特定设备，从而赋予 Corbado 将认证信任层级节节拉高的底气。

• 破解同步通行密钥带来的迷局： 同步的通行密钥为用户带来了极佳的便利性，不过也会引发有关信任的问题。当用户通过这一类通行密钥完成登录认证后，无法直接判断他们此刻用的是常用的笔记本电脑，还是一台刚刚完成凭证资料同步的新配置设备。DBSC 正好补齐了这个盲区。借由核验这台设备上究竟有没有建立起稳定的 DBSC 绑定链路，Corbado 就能确认该设备到底是“老熟客”，还是仅仅进行了首次验证同步作业。
• 为已知设备赋予更高的信任： 若 DBSC 信号证明一台设备此前已被接纳，Corbado 便能够有底气地作风险研判。具体体现为：对于合法的回头客尽量减少额外的进阶认证提示，而针对从陌生设备发起的会话施加更为严苛的审视。
• 补充通行密钥智能： DBSC 生成的信号可与 Corbado 原有的 通行密钥智能引擎相辅相成。基于通行密钥开展的身份验证同以 DBSC 为根基所实现的设备绑定合二为一，成功构建出从最初登录一直持续到完整会话周期终结的信任锁链。

如对 Corbado 计划如何将 DBSC 融入自身平台有所疑问，请直接与团队接洽。

在未来的几年中，Web 环境仍将是混合式的。一部分用户手头会有能够良好支持 DBSC 的浏览器（例如运行于 Windows 11 上的 Chrome）；另一部分用户则在操作较旧的系统平台。这种高度的分裂化会造成难以驾驭的困扰。Corbado 研发的通行密钥智能引擎，正是专门用来妥善解决这些后撤/兼容逻辑而量身打造的——给具备此能力标准的设备投放通行密钥以及对应的服务环境，并为不具备的设备备好相应的替代措施。相同的逻辑理念也适用于会话绑定层面，借此以用户的硬件实力为其获取尽可能多的安全性保障。

“承载令牌”的时代即将落下帷幕。当前使用的会话管理方式存在严重的致命隐患——各类承载令牌都可能会遭到工业级量产化的恶意程序的肆意盗取，并被拿到不同的设备上使用，引发即便有再牢固的认证防线也无济于事的账号全面失陷。正是这种最根本层面存在的漏洞，培育出了一条市值数百亿美元的地下黑灰色交易产业链。

设备绑定会话凭据 (DBSC) 是目前行业内冉冉升起的新答案。传统的带有 HttpOnly 防护参数以及固有保密文本结构的安全 Cookie 的抵御水准已成过往，DBSC 运用由设备硬件锁死管理的独占密钥施加具有“持证”含义的密码学约束保护。此类机制使得被偷走的 Cookie 价值瞬间归零。因为在别人的设备上，它们根本得不到刷新机制的响应。此前的令牌绑定（Token Binding）因为迫切需要在所有的基建网络里大刀阔斧地开展对 TLS 底层的改变从而夭折。相反，DBSC 因为只在 HTTP 这样的应用协议层运行发挥了作用，它能非常融洽地同现有在用的各种负载均衡设备以及 CDN 系统相互搭配。请注意：在浏览器跳过绑定程序（例如 TPM 组件失效，网络阻碍故障等情况）时，DBSC 同样配置有可资追溯查验的后备应对步骤预案，它大幅削减了 Cookie 遭窃风险，却并非彻底的根除它。

DBSC 与通行密钥这两者结合将能在使用过程中拔高抗击侵袭的防护准线。通行密钥可在启动登录流程之初有效化解口令被钓鱼诓骗的厄运，同时，DBSC 大幅增加通过异地取巧调用 Cookie 以图霸占进程会话的实行难度——这两者的相互组合，成功孕育出 FIDO 联盟所畅想与倡导的“高保障水准”安全防护构架全景图。随着 Chrome 146 在 2026 年 4 月已将面向 Windows 端全面提供 DBSC 支持的工作投入实施，另外，在 macOS 操作环境通过安全隔区的支持也在跟进当中，此安全操作标准也就此走过了准备时段，而扎实地转入了广泛播撒普及的新阶段。Google 所正式敲定发布的各项开发日程表（譬如，打通全盘应用环节开展的联合化身份体系识别校验，借力于 mTLS 或者通过实体型硬件配置所推动实行的各类密保登录方案，以及偏向纯软体加密属性生成的各式密钥体系等等）昭告了它即将引燃接下来的长达 12 个月的扩容延展风暴期。

对众位产品经理而言，其蕴含着的商机颇具诱惑：DBSC 让“无尽头式”的可依赖会话成为了现实，极度收敛了因频频要求登录所衍生的各等麻烦阻难。并且，一并减除各类坑骗所造成的流损。另外还有支援层面的维系开销也能明显下降。这番投入收效能化为更为可观的服务使用留存率和顺当无阻转化率的增长体现。那些让人一筹莫展的找寻密码或是挂失解封的投诉请求单数量，也将大跨步回落缩编到绝迹。组织如使用 OAuth 则完全可以通过借助 DPoP 加持在 API 端点的保护上复用其有关的密钥挂钩管理观念逻辑。而将同类相关环节的防护协同到（CAEP/RISC）机制里面，从而为响应处理提供更敏捷及时的实时抵御保护响应体系支持。这相当于给这些曾经被控制被入侵的风险源，布下了在其开启下一个环节验证步骤的瞬刻，直接对其发起强有力的一举歼灭处置的操作条件。

其实这都根本无需劳神费力地非要再专门耗时花大力气搞基础开发基建了。各种已开发出来的托管系统，比如像 Corbado 等此类平台都已经能够自行为客户代为装配各种诸如通行密钥有关基础框架的支持。不仅如此，他们同时还有专门人手密切地在盯着各种有关于如何与各种现今正在快速演进支持 DBSC 操作等浏览器进行对接的技术指标进展。W3C 规范乃是一项在积极编撰中的动态的工作底案文本资料。而 Chrome 146 已然在 Windows 上实行了这方面的全面推出功能并且正在筹谋推行到 macOS 身上，别的诸多浏览器也在紧锣密鼓地开展这套规范化操作体系的研究估算。

未来的发展趋势已不言自明了，现如今如果企业机构越早就动手布局把诸如像通行密钥，或者是包含各种基于类似 DBSC 的设备锁死型验证操作引入其中的业务模块的话，将在此后各类防范钓鱼无密码操作盛行起来的世界里，提前占据最佳的地利方位。故此，是否要推行实行各类基于设备锁死限制型的身份认证保障体系从来都不会是个议论的话题。现在的问题只在于到底如何最快速精准地投入进去以守住自身机构组织在客户心中的信誉评价与安全。将来，属于 Web 这片沃土的安全防范系统肯定绝不再仅仅拘泥在这等所谓已校验操作表面。未来的网络架构必然要求各类信任源紧跟于各类绑定了硬件级的精密保障当中去。

关于 Corbado

Corbado 是面向大规模运行 consumer 身份验证的 CIAM 团队的Passkey Intelligence Platform。我们让你看到 IDP 日志和通用 analytics 工具看不到的内容：哪些设备、操作系统版本、浏览器和 credential manager 支持 passkey，为什么注册没有转化为登录，WebAuthn 流程在哪里失败，以及什么时候操作系统或浏览器更新会悄悄破坏登录 — 而且无需替换 Okta、Auth0、Ping、Cognito 或你自有的 IDP。两款产品：Corbado Observe 提供 针对 passkey 及任何其他登录方式的 observability。Corbado Connect 提供 内置 analytics 的 managed passkey（与你的 IDP 并存）。VicRoads 通过 Corbado 为 500 万以上用户运行 passkey（passkey 激活率 +80%）。 与 Passkey 专家交谈 →

当终端安全工具（如 CrowdStrike）检测到恶意软件时，它们会向身份提供商发送 RISC 信号，后者会将 CAEP“设备已受损”事件推送到连接的应用程序。在下一次 DBSC 刷新尝试（几分钟内）时，这些应用程序将拒绝会话签名并终止访问。跨供应商的 CAEP/RISC 部署目前仍在成熟中。

DPoP (RFC 9449) 在应用层将 OAuth 访问令牌和刷新令牌绑定到公钥，主要用于保护原生应用程序和 SPA 中的 API 调用。DBSC 将浏览器会话 Cookie 绑定到硬件支持的 TPM 密钥，这些密钥是 JavaScript 无法读取或导出的，因此即使 Web 应用程序本身受到 XSS 或恶意软件的攻击，也能保护面向用户的会话。

传统的安全设计要求较短的会话超时时间，以限制 Cookie 被盗和被远程重放所造成的损害。DBSC 将刷新能力绑定到源设备的私钥上，因此从不同设备使用的被盗 Cookie 将无法通过密码学挑战。由于远程重放攻击被抵消，因此会话可以在实际上被无限期延长。

DBSC 消除了作为账户接管主要载体的 Cookie 盗窃，直接降低了欺诈损失和账户恢复支持成本。安全的长时间会话消除了重复的登录提示，从而提高了电子商务中的转化率并减少了用户流失。FIDO 联盟将 DBSC 定位为在提高安全门槛的同时降低用户使用阻力。