3 ms·

Am 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 key

Am 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 ago
Are you checking every token and cookie yourself to make sure they haven't been hijacked?
8organicbits 3y ago
I 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 ago
The 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 ago
Keeping 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.

lightedman 3y ago

Are you checking every token and cookie yourself to make sure they haven't been hijacked?

8organicbits 3y ago

I 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 ago

The 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 ago

Keeping 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.