I think the industry, to some extent, already have reconsidered the session length, see [0] by Auth0 for example (even if it's obv. a PR piece). Nowadays my gut assumption when I use a service with really short sessions is that their security practices are probably questionable.
I recently argued, as the cybersecurity guy™, with a vendor that we can't ask regular users to reauthenticate every 15 minutes. They insisted raising it would be to insecure and instead suggested to make MFA optional as it would make the login process smoother…
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.
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.
> 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.
Some of it depends on regulations and usage context. When I worked in healthcare, sessions were always short-lived. This may have been regulation-driven, but it's also based on the fact that often this software is being used on shared machines or in areas where unauthorized users are present (such as in patient rooms). While users are trained (very well, in my experience) to lock machines whenever they're unattended, short session lengths provide an additional layer of protection.
I saw a demo like 15 or 20 years ago of a Sun thin client that used smart cards. You put your card in to any terminal, and nearly instantly your desktop session was live. Remove the card and it instantly disappears and locks.
That type of thing seems ideally suited to healthcare use, and we have such better devices now than whatever cards were used way back then. Amazing it's still Windows PCs deployed and secured with passwords.
A previous employer (regional healthcare system) did exactly that: staff used their badges (along with another authentication factor, IIRC) to pull up their VDI instance on any client. This was just being rolled out ~8 years ago.
What gets me is that gmail login lasts...seemingly forever. And for most users, if their e-mail account were to get compromised, it's game over for everything they use, since so many services allow you to reset a password and possibly even remove 2FA with just e-mail verification.
What's even the attack scenario? Someone stealing a session token/cookie? If they can steal an expired one somehow, then there are good odds they could steal a current one, so the short session doesn't matter THAT much. I suppose another scenario is someone not logging out of their accounts on a public computer, but the type of person to do that likely uses "Password123!" as a password anyways.
> ... since so many services allow you to reset a password and possibly even remove 2FA with just e-mail verification.
What is insane is that so many services allows to reset password and even 2FA without requiring any cooldown. The level of fail here is plain staggering. I don't really have words.
There are proper services out there who shall go out of their way to try to contact you, for example for 72 hours, before allowing any reset to happen. Some are going to say: "Wait, what!?, 72 hours!? I need to reset my 2FA NOW". They don't realize though that what they're really saying is: "I want bad guys to be able to reset my password/2FA instantly and log me out of everything they can in a split second". It's convenience vs security, once again.
As a sidenote I've read about a DB (in the EU) about SIM cards saying when they were swapped. And as a bank, you can check that DB and decide, for example, to refuse to let anyone change any setting if the SIM was swapped less than a week ago.
We need more people to think a bit about potential solutions instead of crying "but it's not convenient" and "bad guys shall find a way anyway".
A problem which has made the news repeatedly is services where an e.g. password reset doesn't reset / invalidate the session key. How many cases of ridiculously short session expiry are masking cases where the service is unable to actually manage to invalidate a session key in conjunction with said password reset?
I recently argued, as the cybersecurity guy™, with a vendor that we can't ask regular users to reauthenticate every 15 minutes. They insisted raising it would be to insecure and instead suggested to make MFA optional as it would make the login process smoother…
[0]: https://auth0.com/blog/balance-user-experience-and-security-...