Live data from Hacker News

Short session expiration does not help security

sjoerdlangkemper.nl

281–290 of 434 posts

Re: Short session expiration does not help security

#281
As someone that regularly works with malware, cybercrime and SaaS attacks I strongly disagree with this article. One look at Genesis Market is enough to see why "better auth", "2FA", etc, do not solve the problem of malware on the machine stealing cookies (sessions).

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…

It's not even about behaviour.

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.

It reminds me of when I didn't understand why my library account has such a short expiration time. Almost every time I open the library's website, I have to re-enter the password. Why? What's so important about a library account? Who's going to borrow a book on behalf of me?

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

#284
post #279
post #265

Earlier 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?

Dissatisfaction with the speed at which Google does things due to organizational reasons. Lots of smart people working very hard, only to have little to show.

Re: Short session expiration does not help security

#285

Earlier 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…

Sure, there are some attacker activities that are highly automated. That’s not what we’re talking about here. We’re talking about compromised temporal session tokens, which are frequently harvested by manual action, and in those scenarios, thinking about human timeframes is very useful.

Re: Short session expiration does not help security

#286

The 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…

My main bank uses username + password + (random subset of ‘memorable word but actually unencrypted password’ driven by select boxes), then 2FA on top, and it literally feels like they just slapped a bunch of things together to add extra barriers to auth in sequence.

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

#287

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

The mistake is in thinking security is a separate domain from UX. While expertise in it may be, it applies everywhere.

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

#288
post #114
post #28

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

> 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
post #8

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

> 1: A short compromised session is still a compromised session.

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

#290
post #194

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

> I think this is a more elegantly stated version of my argument.

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.

Post reply on HN