LTT YouTube channel has been compromised, account suspended

- hardware enclave contains public and private key pair

- browser retrieves public key, sends to remote host (website)

- website sends back a unique token with the response to every valid request from that client (kinda like anti-csrf tokens)

- browser asks enclave to write a message containing that token, signed with private key

- when the browser sends the next request, include the cryptographically signed message containing the last token received by the server

- website checks that the returned signed message includes the correct token, and has a valid cryptographic signature matching the provided pubkey

this would be entirely transparent to the end user and would prevent simple replay attacks with the token, which seems to be Gigachad's idea (prevent it from being transferred)

unfortunately, as you point out, even provided the adversary cannot retrieve the private key, this means that as long as the secure enclave is connected and accessible, and as long as the adversary maintains code execution on the victim machine, the attacker could simply issue requests necessary to perform account takeover from the victim machine, rather than their own machine.

in security, it is extremely challenging to design systems that remain secure even when an adversary has access equal to or exceeding that of legitimate, authorized users, as is typically the case when malware is dropped on a machine, which is probably the most common way cookies with secure and httponly flags set get stolen.

Sadly, the security model of most x86 operating systems like Windows is well-suited to protecting system administrative functions, like installing drivers, but is poorly suited to protecting ring 3 / userland software (like the cookies from your browser, which are stored on disk) from other ring 3 / userland software (like that cookie stealer that just got ran with the same privileges of your freshly-exploited PDF reader)

obligatory xkcd: https://xkcd.com/1200/

Somewhat interestly, the security model of modern mobile operating systems like Android and iOS is ostensibly much better at protecting against threats like this - even if you install a blatantly malicious app, if you're not rooted, that app is not able to simply read your browser's cookie file from disk. That sort of security model can feel extremely restrictive from the perspective of 'typical' x86 OS users, but will feel right at home for anyone using special compartmentalization-based security-focused OS's like Qubes, where your PDF reader gets opened in a disposable VM entirely distinct from your browser's VM. This isn't unhackable, but as someone who hacks for a living (red team at big tech co), it's a barrier that would stop me unless a fresh, public Xen escape CVE drops tomorrow.