4 ms·
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
by filleokus 3y ago
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…
[0]: https://auth0.com/blog/balance-user-experience-and-security-to-retain-customers/ https://auth0.com/blog/balance-user-experience-and-security-...
- organsnyder 3y agoSome 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.
- gregmac 3y agoI 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.
- organsnyder 3y agoA 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.
- Sohcahtoa82 3y agoWhat 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.
- TacticalCoder 3y ago> ... 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".
- gregmac 3y agoThe 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 agoFor 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
- joquarky 3y agoNIST recommends creating separate "Authenticator Assurance Levels" to balance security with UX: https://pages.nist.gov/800-63-3-Implementation-Resources/63B/AAL/ https://pages.nist.gov/800-63-3-Implementation-Resources/63B...
- m3047 3y agoA 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?