4 ms·
X for Doubt. There's almost no details that are useful in this article, and in this case, the authors indicating Google isn't doing anything about it is likely
by rezonant 3y ago
X for Doubt. There's almost no details that are useful in this article, and in this case, the authors indicating Google isn't doing anything about it is likely because this isn't actually true.
Of course maybe I'm wrong but short of some more compelling technical details (reply a link if there's a better source), I'm inclined to doubt the characterization of this article.
EDIT: Sibling linked https://www.bleepingcomputer.com/news/security/malware-abuses-google-oauth-endpoint-to-revive-cookies-hijack-accounts/ https://www.bleepingcomputer.com/news/security/malware-abuse... which is more technical.
- deleted 3y ago[deleted]
- 8organicbits 3y agoI generally believe it. Google's security team has been lax on cookie security. I reported an issue earlier this year about non-expiring session cookies; they said it was previously reported in 2019. The bug remains [1]. Sadly other Google projects use this code... Historically they've been quick to patch things I've reported, so it feels like a decline. [1] https://github.com/googleapis/nodejs-firestore-session/issues/63#issuecomment-1684098874 https://github.com/googleapis/nodejs-firestore-session/issue...
- londons_explore 3y agoAm I the only one who wants non-expiring sessions. My browser cookie store ought to be a good place to store secrets. On Linux it is protected by the user keyring. I believe on windows it is protected by the system secret store which is eventually secured by the user logon password and the TPM. So why not just let my cookies survive until I explicitly invalidate them by clearing my cookie store, hitting logout, or by changing my account password? From a security perspective, someone who breaks into my cookie store has access to pretty much any website I use, whether the validity is 1 week or 1 century. Any prepared attacker can take full control of the account in a matter of minutes, so the validity doesn't make much of a difference.
- lightedman 3y agoAre you checking every token and cookie yourself to make sure they haven't been hijacked?
- 8organicbits 3y agoI worry about a couple things. Many apps don't end other sessions when you log out or change passwords. My example above doesn't handle that. Poorly written backends only check if a user is active during login. So a lingering session remains usable. Imagine an employee is fired, they are angry, their accounts is disabled, but they still have access. In some rare cases sessions for deleted users still work. You'll see this most often with apps that rely on client side cookie expiration as sessions appear to expire, but they don't. Personally, I want short sessions on things like my bank account. For stuff like HN, long is great.
- SpaghettiCthulu 3y agoThe problem here is that the cookies don't expire even after changing the account password. The account owner must manually end each session from the accounts.google.com page.
- Dylan16807 3y agoKeeping sessions alive is useful, but there are lots of ways to improve security without losing much convenience. Sessions shouldn't live longer on the server than on the client, that's just silly. The cookie associated with a session should be updated with moderate frequency, and old cookies should be invalidated. If a particular client doesn't connect for long enough, it should probably have its session revoked.