3 ms·

The thing that I find super frustrating about these short sessions is the lack of risk it's mitigating. If it's expiring in a few minutes, presumably you're tr

The thing that I find super frustrating about these short sessions is the lack of risk it's mitigating. If it's expiring in a few minutes, presumably you're trying to protect against two things: (1) Session hijacking and (2) Unlocked computer. Session hijacking is somewhat preventable via other means (eg: IP address tracking), but more importantly, in what case can a session be hijacked only 15 minutes later? Someone walking away from an unlocked computer is an impossible problem for a app/site to solve. If an attacker has access to the PC, they can install malware that sniffs all traffic or passwords, and if the user saves their password(s) on their PC all of those are compromised anyway. This is a responsibility of the person responsible for the computer -- eg, the user and/or the IT admin. When sessions/passwords expire in a time measured in days, I can't help but think they are basically saying "it's okay for an attacker to have access to this system for 89 days... but not 90!" The only valid argument I've ever heard for this is an attacker might be doing offline cracks of passwords -- but there's so many other fails involved there that I can't see how blindly expiring them is at all useful by comparison. Not to mention rotated passwords are very predictable[1] so it's unlikely to even mitigate the attack. [1] https://www.sans.org/blog/the-debate-around-password-rotation-policies/ https://www.sans.org/blog/the-debate-around-password-rotatio...

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

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