Chrome Adds Anti-Theft Cookie Protection While Researchers Show Passkeys Aren't Bulletproof on Windows

Google is rolling out a new Chrome feature meant to kill one of the most effective tricks in a hacker's playbook: stealing your login session instead of your password.

The feature is called device-bound session credentials, or DBSC. It's available now in Chrome 147 for Windows and Chrome 150 for macOS, though Google has it switched on for only a limited set of users while it tests the rollout, according to Ars Technica.

Here's the problem it solves. Websites use session cookies so you don't have to log in every time you click a new page. Once you authenticate, the cookie proves you're already verified. Attackers figured out that if they steal that cookie with infostealer malware, they can paste it into their own browser and walk right into your account, no password or two-factor code required.

DBSC shuts that down by tying the cookie to a cryptographic key generated and locked inside your device's hardware, the Trusted Platform Module on Windows or the Secure Enclave on Apple devices. Scott Helme, founder of Report URI, explained the core protection to Ars Technica: "The attacker can't steal the private key from the device because the TPM/Secure Enclave will not release it." Steal the cookie all you want. Without the hardware-bound signature, it's useless.

That's a genuinely strong fix for a real and growing attack vector. Session hijacking has exploded precisely because passwords and even 2FA got harder to phish directly.

But passkeys have their own soft spot

While Chrome patches one hole, researchers at Palo Alto Networks' Unit 42 spent the past several days publicizing a separate weakness in how Google Password Manager handles passkeys on Windows.

The research, detailed by BleepingComputer and The Hacker News, describes three attack chains collectively dubbed Pass-ta-key. All three require malware already running on a victim's Windows machine, meaning the computer has already been compromised before any of this works. None of the attacks break the actual cryptography behind passkeys.

Instead, according to The Hacker News, they exploit "the code around the passkey: how Chrome stores its device keys, how it re-enrolls a device after that state disappears, and whether the site you're signing into bothers to check that a human was verified at all."

The base-level Pass-ta-key attack lets unprivileged malware impersonate a trusted device and get a valid login response for one of the victim's passkeys, without a fingerprint, PIN, or any prompt appearing on screen. Unit 42 said the attack failed against GitHub because GitHub properly checks whether user verification actually happened. It succeeded against eBay, which required verification but didn't correctly validate the flag confirming it occurred. eBay has since fixed the issue after Unit 42 reported it, according to BleepingComputer.

The more advanced versions go further. "Silver Pass-ta-key" lets an attacker register their own verification key with Google's cloud authenticator by forcing a device re-enrollment. The strongest version, referenced by The Hacker News as targeting the 32-byte Security Domain Secret, can extract the master key protecting a user's entire set of synced passkeys, potentially giving attackers reusable access from their own machine even after the original infection is cleaned up.

Arie Olshtein, the Unit 42 researcher behind the work, told The Hacker News that no CVE has been assigned to any of the three techniques. "Google rarely assigns CVEs to issues that require the device to already be compromised by malware," he said. Olshtein confirmed the demonstrations were built against Chrome 142 and, aside from one logging issue Google has since addressed, "the attacks still worked against the current stable version" as of early August.

PC Perspective's coverage framed the finding with more skepticism than the other outlets, noting the underlying issue traces back to a FIDO Alliance design decision: the alliance let operating systems decide how strictly to protect locally stored passkeys, rather than mandating hardware isolation, so that passkeys could still be copied to new devices without starting over. Windows' more permissive privilege model, PC Perspective argued, made it the weak link, and the outlet questioned whether Pass-ta-key was really "the novel attack it was billed as" given that it largely abuses Google's own built-in device-migration feature rather than a brand-new flaw.

None of this makes passkeys worthless. Every attack path starts with malware already on the machine, which is a much higher bar than the phishing emails that crack plain passwords. A compromised device is bad news for any credential system, passkeys included.

But it's a useful correction to the narrative that passkeys are unphishable and therefore invulnerable. They're unphishable. They're not immune to a machine that's already been owned.

Unit 42's report gives no evidence these techniques have been used in real-world attacks, and no complete list of which Chrome versions remain exploitable beyond confirming the issue persisted in the current stable release as of Olshtein's early-August comments. Google has not published a public timeline for closing the remaining gaps in Google Password Manager's device re-enrollment and verification-flag checks, leaving an open question for the millions of Windows users who've adopted passkeys as their primary login method.