I'll take that risk, especially since I've basically never heard of a successful attack hinging on a stolen session cookie being used for months. Either you do what you'll do within a few minutes, or you never do.

That's a great way for someone to siphon a lot of session tokens and then auction them off to a black hat.

It's also a great way to lose everything if you happen to lose your phone or laptop and it gets found a few hours or a day later and the antagonistic finder guesses your weak PIN.

In the US, service providers and manufacturers are often held liable for losses if they make something that has sub-standard security. Kia, for example, was held liable for making their cars too easy to steal. Banks have boatloads of things they have to do to protect their customers.

It's not really your choice to take the risk here, apparently.

When was the last time that happened to a Gmail account? It has unlimited cookie sessions.

I actually did this for my small saas Ive sold to a couple dozen companies, and while all my programming friends at the coworking office said I was crazy, Gmail and facebook were my go to answers. If they can do it safely, I might as well try.

Username checks out!

Yes, they made the account to post that comment. Might as well make the username relevant.

Ugh. Account created 1 day ago. My mistake. I do apologize for wasting everyone's time and thank you for pointing it out.

Maybe Gmail, but definitely not GCP. I have to re-auth every day or two for that.

And even with Gmail there's a decent chance it isn't just "blindly trust unlimited-duration token". Cookie stealing is now one of the main forms of credential compromise, so I bet there's some form of browser and/or IP verification going on to demand a reauth when some `curl` instance from a Russian VM tries to make use of it...

Then connect the browser directly to the secure element of the device, so the session cookie is cryptographically signed by something you are physically in possession of.

Logging and alerting the user that their account is being used from a new context and requiring reauthentication when accessing the account from an unfamiliar IP/user agent would mitigate this to some extent.

The alternative is offering offline versions of apps to students and allow students to open downloaded items off the cloud locally. It also means students don't require internet access when off campus.

TPMs / secure enclaves can (in theory) prevent sessions or cookies from being stolen. Not claiming there aren't other attack vectors though.

Are those used in practice, though? I'm not aware of any "sign request headers with private key cookie stored in TPM" HTTP extension, but I would love to be proven wrong.

Of course, in practice that would just turn cookie-stealer malware into request-proxying malware.