Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Short session expiration does not help security

sjoerdlangkemper.nl

Post reply on HN
Print view View original

131–140 of 434 posts

Re: Short session expiration does not help security

#131

Post by nightpool »

galdor wrote: post #96
horsawlarway wrote: post #20

Earlier quoted context omitted.

> Google's sessions do not expire, so that more user data can be collected. That is clearly more valuable to them, than compromised accounts due to session hijacking. Them doing it, is not a great use case for others, because their value proposition is entirely different than for most other web applications. I think this is a pretty bad take. Google runs some very sensitive applications for paying enterprise customer…

> Google runs some very sensitive applications for paying enterprise customers, and they still tend to not expire sessions. For Google Workspace, web applications (e.g. Gmail or Calendar) will regularly force you to re-authenticate "for your security". It's not a daily thing fortunately, but it is common enough to be frustrating.

Session expiration length is a configurable setting by the domain admin, it's not enabled by default.

Re: Short session expiration does not help security

#132

Post by marcus0x62 »

TeMPOraL wrote: post #61
marcus0x62 wrote: post #43

Earlier quoted context omitted.

> 1: A short compromised session is still a compromised session. The duration usually does not prevent the attacker from achieving their goal. Need a citation on that “usually” part. A short session duration most definitely: * Makes it less likely that when an attacker obtains a session token that is is unexpired. * Gives the attacker less time to use a valid session token to move laterally into (potentially) unfamil…

> * Makes it less likely that when an attacker obtains a session token that is is unexpired. But gives them more opportunities to acquire such token. > * Gives the attacker less time to use a valid session token to move laterally into (potentially) unfamiliar infrastructure. Only if tokens lifespan is counted in milliseconds. Otherwise, the attacker will refresh the session token as soon as they get it, and continue…

> But gives them more opportunities to acquire such token.

Maybe, if the session tokens are being acquired by improper logging. If the tokens are acquired via the user’s cookie store, for instance, the total number of session tokens is going to be the same — the user is going to use the applications they use, and the stored session tokens will reflect that.

> Only if tokens lifespan is counted in milliseconds. Otherwise, the attacker will refresh the session token as soon as they get it, and continue to do so. An active session token can be thought as having arbitrary long lifespan.

If the session timeout is based on inactivity, not total life time.

There are instances where session timeouts/forced reauth are useful and where an attacker could not endlessly refresh the token.

Re: Short session expiration does not help security

#133

Post by marcus0x62 »

horsawlarway wrote: post #106
klodolph wrote: post #67

Earlier quoted context omitted.

That’s one possible scenario. The correct way to evaluate security is to consider many different scenarios, and consider how your mitigations affect the likelihoods of all of them, weighted by their impact.

> The correct way to evaluate security is to consider many different scenarios, and consider how your mitigations affect the likelihoods of all of them, weighted by their impact. NO! that's merely the FIRST step in evaluating security. The next steps are: What sort of threat am I attempting to prevent? How do my mitigations impact usefulness of the product on the whole? And most critically: Are my users better served…

> My proposal is simple: Actually do the damn evaluation, instead of just blindly siding with "moar security = moar better!"

Agree 100% on this.

Re: Short session expiration does not help security

#134

Post by horsawlarway »

jameshart wrote: post #97
generalizations wrote: post #90

Earlier quoted context omitted.

The point is that it's a really bad tradeoff, because the impact to the users is high, and the impact to security is low. And yet we do it, because "You don't stop securing it just because you've found one good option", and that's a really bad reason to improve security by such a small increment with such large negative consequences. The problem with 'defense in depth' is that it comes as close as possible to locking…

That's a reasonable point, sure. One which can be made reasonably, without telling anyone that their attitude is cancerous.

I don't think that appealing to courtesy is really the play here.

We are discussing ideas about security in a place and manner that allows us to have honest and frank conversations.

I think security teams optimizing only for security is actually very apt analogy to cancer: Part of the organization is acting in a manner that is negatively impacting the organization at large - while positively impacting that subset of the organization.

Cancer is the act of some cells in your body prioritizing themselves at the expense of the whole.

Personally - I think you're digging to find an insult in that comment, and I take it as a way for you to disengage with the topic at large.

This is an attitude that is routinely used to shut out voices that don't match the current "dress code".

Trust me, I'm hardly going to be calling you cancer over the dinner table for not passing the salt. I'm using that word intentionally and carefully - in a frank and honest conversation. If you're feeling hurt (especially on behalf of someone else...) maybe go do something else?

Re: Short session expiration does not help security

#135

Post by jmull »

klodolph wrote: 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…

> This one line is emblematic of the flaws in the article.

I don't think you can reasonably dismiss this article based on that line.

(1) It's just an aside, not part of the main argument; (2) It happens to be true.

Anyway... "Who knows, it might help" is OK (well, better than nothing), when there's not a significant cost to pay. But when there is, you need to go deeper.

There's a tradeoff being made and if you don't think of it that way, you're going to make a poor decision.

Re: Short session expiration does not help security

#136

Post by [deleted] »

Nextgrid wrote: post #21

In a lot of cases, short session expiry is used as a hack around subpar authentication standards such as SAML/OIDC where there is no reliable backchannel for the identity provider to tell the service to expire sessions (following a credential change, user being deleted, etc). The short session expiry is used as a workaround to force the third-party service to regularly check-in with the identity provider, thus placin…

[deleted]

Re: Short session expiration does not help security

#137

Post by rrrpfb11 »

horsawlarway wrote: post #18
klodolph wrote: 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…

> Security is ALWAYS (fucking always, yes really - fucking always) a tradeoff.

It’s helpful to me that ACLs prevent me seeing other users’ files. I’m not trading anything off that I’m aware of.

Re: Short session expiration does not help security

#138

Post by horsawlarway »

cuu508 wrote: post #82
horsawlarway wrote: post #26

Earlier quoted context omitted.

> Not perfect of course, but limit the exposure. It's a shared computer (and if the session is carrying over, it's not just shared hardware it's a shared account). In this case - you are utterly fucked if you think that machine is secure. Hell, fuck the session, I'll just run a keylogger (or if I'm not admin, install a malicious browser extension) and capture your whole login - I have considerably more access to this…

Let's say the bank also uses 2FA (say, physical code calculators) - your next step?

Install system malware - wait for next login (which will be soon, since the short session is forcing repeated logins) send session token to myself.

Done. Now I have an active session. Don't give a fuuuuck about that 2fa device.

Re: Short session expiration does not help security

#139

Post by njarboe »

"short session timeouts, such as after 15 minutes of inactivity"

I wish my bank, credit card, brokerage websites gave me 15 minutes of inactivity. It seems most have set it at about 5 minutes. My finances are not trivial so I am often logged out when paying bills, figuring out my budget, planning a big purchase, etc. I don't think there is any way to set it to my preferred value.

Re: Short session expiration does not help security

#140

Post by ahtihn »

cj wrote: post #50
horsawlarway wrote: post #33

Earlier quoted context omitted.

> Nonsense, defence in depth is a core security principle. You should not rely on a single control to protect you. And you should not prioritize security over the goal of the product. The conversation is a discussion of relative value and tradeoffs. Does increasing security make the tool as a whole worse? Sometimes - the answer is yes. I have a nice set of front windows, but that means a risk of someone breaking thro…

The idea of “adaptive security” is compelling. E.g. my bank makes me type my password and sends 2fa codes when initiating/approving wire transfers… even when I just logged in a minute ago. If I’m doing 2 wire transfers in a row, it doesn’t care, it still has me fully reauthenticate for every wire transfer. But I’m fine with that because moving money is something that I’m willing to accept however many roadblocks are…

> But I’m fine with that because moving money is something that I’m willing to accept however many roadblocks are thrown at me.

Really? I'd change banks over that. If I log into my e-banking website, the main activity I'm going to do is pay bills. I would absolutely not tolerate having to jump through hoops to do it.

Post reply on HN