Chrome rolls out hardware-bound session protection to combat infostealer malware

Google has announced the public rollout of Device Bound Session Credentials (DBSC) in Chrome 146 for Windows, introducing a hardware-backed mechanism designed to prevent session cookie theft.

The feature will expand to macOS in a future release, marking a broader effort to curb account hijacking driven by infostealer malware.

The technology, which expands existing measures, has undergone testing through Origin Trials over the past year, with participation from major identity and security platforms such as Okta, and input from members of the W3C Web Application Security Working Group. According to Google, telemetry from early deployments shows a measurable reduction in successful session hijacking attempts on services that implemented the protocol.

Session theft remains a significant cybersecurity issue, primarily fueled by infostealer malware. These threats infect endpoints and extract authentication cookies from browsers or capture them after login events. Because cookies often remain valid for extended periods, attackers can reuse them to bypass authentication controls, including passwords and, in some cases, multi-factor authentication. Stolen sessions are frequently aggregated and traded across cybercrime marketplaces, enabling widespread account compromise.

The DBSC protocol works by binding session cookies to a specific device using hardware-backed cryptographic keys. On Windows systems, this relies on the Trusted Platform Module (TPM), while macOS devices use the Secure Enclave. When a user authenticates, Chrome generates a unique public-private key pair stored securely on the device, with the private key never leaving the hardware. Servers then require proof of possession of this private key before issuing or refreshing short-lived session cookies.

This approach renders stolen cookies effectively useless. Even if malware exfiltrates the cookie data, attackers cannot authenticate without access to the device-bound private key. Additionally, DBSC enforces frequent cookie rotation, further reducing the window of opportunity for misuse.

Google emphasized that DBSC was designed with privacy safeguards in place. Each session uses a separate cryptographic key, preventing cross-session or cross-site tracking. The protocol also avoids exposing persistent device identifiers or attestation data, limiting the information shared with servers strictly to what is needed for authentication.

Google plans to expand DBSC capabilities to support federated identity systems, ensuring device-bound security persists across Single Sign-On (SSO) workflows. Additional enhancements include integrating pre-existing trusted credentials such as hardware security keys or mTLS certificates, and exploring software-based implementations for devices lacking dedicated secure hardware.