4 ms·
For very short sessions that is likely true. But I think there is a middle ground where devices are lost or stolen, or data is accidentally leaked. If it is a s
by kevincox 3y ago
For very short sessions that is likely true. But I think there is a middle ground where devices are lost or stolen, or data is accidentally leaked. If it is a sophisticated targeted attack you have already lost. But maybe someone just threw out an old PC that they haven't used in years and the disk isn't encrypted.
For my service I ended up doing something in between. Sessions last for 14 days, but they are automatically renewed indefinitely. So as long as you access the service every 14 days your session will never expire. This way lost or leaked credentials aren't a risk forever. But in most cases users rarely if ever need to log in again. I may play with the exact timeframes, or maybe significantly extend the validity if the user is logged in via the same IP or similar heuristics. But I like that after some definite period old creds are no longer live.
- gregmac 3y ago> where devices are lost or stolen, or data is accidentally leaked > someone just threw out an old PC that they haven't used in years and the disk isn't encrypted. These are scenarios where I think expiration doesn't help at all. I assume your reaction is not just "oh well, the compromised sessions on that device will expire in 70-ish days so we can just ignore it" but instead you immediately consider everything on the device compromised and kill all sessions, rotate all account passwords, etc. If it takes you a day or two to notice this event happened, expiration doesn't help: long expiration hasn't happened yet, and with a short expiration, you still don't know and can't assume it protected anything. In fact, the safe thing is to assume the session was accessed within minutes of the incident. > For my service I ended up doing something in between. Sessions last for 14 days, but they are automatically renewed indefinitely. This is a pretty rational approach, but of course the time frame depends on your users and how they user your system. Auth0 has a good rationale behind their approach[1]: > You can configure session limits with up to 100 days of inactivity (idle timeout) and up to one year in total duration (absolute timeout). > The motivation behind the 100-day idle timeout cap is to cover one quarter plus a few days, which provides wiggle room for people who log in to do end-of-quarter reports. [1] https://auth0.com/blog/balance-user-experience-and-security-to-retain-customers/ https://auth0.com/blog/balance-user-experience-and-security-...