Top Tweets for #dbsc

I wanted to address the speculation about the recently introduced Device Bound Session Credentials (DBSC) security feature in Google Chrome. Does it help increase the security of session cookies against infostealer malware and MFA phishing? The feature has been available and enabled by default since the Chrome 146 update (April 2026), if you're running Windows with a hardware-backed TPM security module (macOS support is coming in future updates). DBSC allows the browser to upgrade session cookies from long-lived to short-lived, requiring the browser to refresh them approximately every 10 minutes to maintain access to the user's account. > Does DBSC prevent account takeover by threat actors using a stolen session cookie obtained from the user's browser via infostealer malware? Yes (kind of). The extracted session cookie will be valid for up to 10 minutes from the time it is extracted. The attacker will be unable to maintain long-term access to the user's account. Still, the timeframe may be sufficient, for example, to exfiltrate the inbox if the attack is automated. The attacker cannot refresh the short-lived session cookie because it requires the private key (stored in the TPM) assigned to the account to sign the challenge. The malware cannot access the private keys stored in the TPM. > Does DBSC prevent account takeover by threat actors during a phishing attack? No. Servers need to provide legacy support for the browsers that do not yet support DBSC. By default, the server registers and sends a long-lived session cookie to the browser. If the server supports DBSC, it will announce the DBSC API endpoint URL in the `Secure-Session-Registration` HTTP header of the response packet that contains the long-lived session cookies. Only after the short-lived session cookie is registered via the DBSC API endpoint is the long-lived session cookie invalidated. When the attacker removes the `Secure-Session-Registration` HTTP header retrieved from the server during a phishing attack, the browser will continue using long-lived session cookies and assume the server does not support DBSC. In short, removing that HTTP header while proxying traffic during a phishing attack allows the attacker to maintain long-term access to the user's account using the stolen long-lived session cookie. I hope I've managed to clear up some confusion. On a related note, you will soon be able to simulate phishing attacks against Google Workspace accounts (and other websites) that bypass DBSC and MFA protections using Evilginx Pro with the Phishlets 2.0 update.