Short session expiration does not help security
281–290 of 434 posts
Re: Short session expiration does not help security
#282> Perhaps you used the shared computer in the library to access your web application, and forgot to log out. > Is this a thing? Are shared computers without user separation a thing? If so, these shouldn’t be used to access web applications with sensitive information at all. Yes, it is a thing. I understand you would like it to not be a thing.
Heh, author gave a perfectly reasonable example of where use might be shared, and immediately asked "Is this a thing?". Like, yes. It is. You literally JUST gave me an example of it. Also this, shortly after: > Are shared computers without user separation a thing? If so, these shouldn’t be used to access web applications with sensitive information at all That "should" is doing a lot of heavy lifting. You don't decide…
Some government services switching over to fully digital means there's a cohort of people being left behind. A decreasing number, sure, but a number nonetheless.
Effectively the author is saying poor people who need to use library PCs shouldn't get security.
Re: Short session expiration does not help security
#283> Perhaps you used the shared computer in the library to access your web application, and forgot to log out. > Is this a thing? Are shared computers without user separation a thing? If so, these shouldn’t be used to access web applications with sensitive information at all. Yes, it is a thing. I understand you would like it to not be a thing.
And then I realized that logging into your library account is probably one of the most frequent things on all the shared computers in the library.
Re: Short session expiration does not help security
#284Earlier quoted context omitted.
> major corporations like Google don't use short sessions Ask a Google employee. When I worked there sessions were limited to 20 hours. Beyond that full re-authentication with password + security key would be needed.
Why'd you leave?
Re: Short session expiration does not help security
#285Earlier quoted context omitted.
> Machines hack differently than humans. An awful lot of hacking is done manually, by humans. For many scenarios, considering human timeframes is completely reasonable.
We live in a world where real time advertising auctions happen. If you think there’s something about that which can’t apply to organized crime you’re gonna be in for a rude awakening when your systems start to fail en masse. I’ve had to replace a credit card twice for suspicious activity (once cost me my favorite domain name, which is still parked). There were no major charges in either case. One charge at a business…
Re: Short session expiration does not help security
#286The main place I see short session expirations is on banking and financial apps, which seems defensible to me for a couple of reasons: 1) They're used by a wide variety of people, including people who may not own a computer or mobile device, or who may not have a backup device to use when their personal device breaks. This group is probably shrinking—more and more people have smartphones and the remaining people who…
This is the UK. Back in Latvia I would just slide my ID card into a USB reader and cryptographically sign the session with a passcode. Same as chip & pin.
Re: Short session expiration does not help security
#287This one seems prone to bias. Out of all the people disagreeing in the comments who actually takes a position against self interest? 1) Security is more your focus than UX, but you agree with the article. 2) UX is more your focus than security, but you disagree with the article.
To draw a comparison here, should we assume that the author advocates for phones or desktops which do not automatically lock after a set period? It's a similar threat vector (unattended phone/pc) in the physical world. I'd assume no, because the specifics of that threat model are different.
This is true of other software as well.
UX and security are only at odds in the grey areas. I'd wager most people posting here -- regardless of affiliation -- would be upset if their web banking solution didn't expire their sessions for days.
Re: Short session expiration does not help security
#288Earlier quoted context omitted.
This is correct, but its uncharitable to call it a "hack" in many contexts. In oauth, for example, the access token / refresh token concept is literally spelled out in the spec. It's not a workaround, its how you implement eventual consistency in a loosely coupled system where the IDP can't push updates to clients because it doesn't know all of them by design
Hang on, we're talking about user sessions and you're talking about access tokens. Short expiration of sessions is bad because of the terrible UX. Access tokens can be refreshed without user interaction, so it's not the same issue there.
Not on mobile, when the app is not in foreground or gets killed by "energy saver" mechanisms - Samsung is fucking annoying in that regard, even on 4GB RAM and more it keeps closing Chrome with 10 tabs after a minute or two and it completely loses state, as do many games - even taking a call in foreground can be enough.
Re: Short session expiration does not help security
#289> Also, it would be better to protect against this by securing the logs or using hard drive encryption. This one line is emblematic of the flaws in the article. My take on the article is, “Imagine that everything else in a system is done correctly, and the system, overall, is perfectly secure. In this imaginary world, short sessions don’t help.” One fact about security which you cannot avoid is that any one particula…
> Short sessions are there because there are various ways that sessions could be compromised. You haven't actually addressed either of the author's points, though. Namely: 1: A short compromised session is still a compromised session. The duration usually does not prevent the attacker from achieving their goal. 2: The vast majority of ways to compromise a session already give you access far beyond that session itself…
But an expired compromised session is not a compromised session.
If a session cookie/ID is compromised after it has expired it is no use to anyone.
But if a session cookie/ID has no expiry built in, then it remains an open compromise risk forever.
Situations where we can expect the session identifier and the context in which it is stored to reasonably be under the control of the user for a short time - while they are actively using a site, say - but where it might not remain under their control after they've finished using it, are a real part of real threat models.
If I have some cross-site-request-forgery phishing scam that works on users who are logged in to a bank website, that requires them to have an active session at the time they open their email, or visit my site, or whatever... if their banking sessions time out after 15 minutes of inactivity, they are less vulnerable to that threat than if their browsers keep them logged in all the time.
Re: Short session expiration does not help security
#290Earlier quoted context omitted.
> Note that "You don't stop securing it just because you've found one good option" is NOT the same thing as saying "You don't stop securing it until you've closed every possible security gap and compromised usability". It seems to me that 'defense-in-depth' can very easily become a mantra that inevitably means drifting towards the latter. What are the real guidelines for telling when enough is enough? Because ime peo…
I think this is a more elegantly stated version of my argument. It's also why I strongly link this argument to cancer. It's an idea that grows unbounded until it's harmful, and by the time the organization realizes the harm, it's often too late to change.
Yep. I think your argument pretty much conveyed the same thing, along with a lot of anger and frustration.
I also agree with that anger and frustration— I've felt the same rage before, when I've been hit with blockers or UX degradation related to nominal or actual attempts to improve security. Restrictions that are ill-motivated (or whose motivations are just not clearly or convincingly communicated) are infuriating.
> by the time the organization realizes the harm, it's often too late to change.
This worry is the twin of the rage, for me, this sense that I can't do anything about it and it's never going to get better. A dreadful, reluctant admission to myself that the only way to stop the continual degradation of my work life will be to uproot myself: give up my job and everything I do like about it, leaving behind people I enjoy working with and reducing the amount of contact I have with them.
Happily, engaging directly with my company's infosec department directly often gives me hope and allays these fears somewhat. But generally, online discussion with people who implement security controls tends to reinforce my worry that, to borrow your metaphor, the disease is systemic and terminal.
Most 'cybersecurity professionals' (who are visible online, at least) transparently do not give a shit about UX, display flagrantly antagonistic attitudes about users and developers, and talk often about defense-in-depth but never articulate any inherent limits for appeals to defense-in-depth beyond 'well don't bother with measures that don't increase security at all'. All of it sends strong signals that people who value UX, DX, autonomy, morale, and well-being, to the extent they are present at all, are outliers in infosec who do not belong and have no hope of being effective.
And then the response to someone openly including a dimension of emotionality in an argument about a security measure they feel is gratuitous and cumbersome is
> Did... did [a cumbersome security measure] hurt you?
Like, seriously? Yes. Indeed it did and does.
But more than the security measures themselves, the pervasive attitude conveyed by that belittling question is the even bigger problem. And it generates many of the small ones.