Live data from Hacker News

Short session expiration does not help security

sjoerdlangkemper.nl

181–190 of 434 posts

Re: Short session expiration does not help security

#181
post #24

Is there a list of "security advice that doesn't really make sense but we keep following just because"? This is a great one, another good one is regularly changing passwords. What else?

> another good one is regularly changing passwords

I believe someone stuck forced password changes in legal banking regulations at least in the EU. In spite of all having hardware or mobile based tokens.

Needless to say, I just increment a number 10 times, because they "prevent password reuse" as well.

Re: Short session expiration does not help security

#182

What I wonder is why do we apply such different standards/expectations to web and non web apps? E.g. desktop Slack doesn’t ask me to log in all the time. Are web app tokens that much more easily stolen? What about Electron apps then?

Web pages share browser with other web pages, desktop apps don't.

Re: Short session expiration does not help security

#183
post #22

Also, not respecting your own "Remember me" checkboxes does not make happy customers.

My pet theory on this is developers never test it and QA rarely do either. Both groups are logging in/out constantly and if that checkbox doesn't work it's easy to fob off as "maybe I didn't check it?" or "my account switching broke it but that's a special case". Every time I have to login again to a website that I told to remember me or "trust this computer" I get frustrated and then immediately think "Ehh, I unders…

You'd think simple log in/log out test would be trivial to automate...

Re: Short session expiration does not help security

#184

ANY session expiration does not help security. Authentication should not involve time. If I logged in, I should stay logged in until I explicitly log out. That's it. The session should live forever or at least several years from the last time I used it. Speaking of internet cafes and other shared computers, they usually are secure enough. All internet cafes I've ever been to run specialized management software on the…

This is an insane take; if your session token is buried somewhere in a log and gets discovered after a few hours, it shouldn't even be remotely possible that it's still valid.

Re: Short session expiration does not help security

#185
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.

"Session" here is the word used for the duration in which an access token is valid. You may be talking about UX, but the submission is talking about access tokens.

Re: Short session expiration does not help security

#186
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 don't have smartphones are probably also the people without bank accounts—but arguably you want to cater to this group, since they may already be a bigger target for scams.

2) They're very appealing to opportunistic attackers.

3) They're used by people in stressful or unusual circumstances, e.g., when traveling, if they need to make a large emergency payment, or if they're afraid of being scammed.

4) Most sessions aren't very long anyway: checking a balance, seeing whether your paycheck came in, making a single transfer or payment, etc. There are definitely exceptions—15-minute timeouts are very annoying when doing taxes, for example—but it seems like the annoyance in these situations is potentially worth the security benefits.

That being said, I don't know if short session expiration is the best solution in 2023. As the article points out, major corporations like Google don't use short sessions, even though their services are used for a variety of sensitive things and they're huge targets. But as briHass pointed out in another comment, they also provide tools to see which sessions are open and use a variety of techniques to detect sessions being misused. I suspect that's the actual best solution if avoiding session stealing is that big of a concern.

Re: Short session expiration does not help security

#187
post #28

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…

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

It's fair to argue that point. If you need something like that, then this aspect of OIDC etc. is not a hack. But really really few people take a look at the question of how to integrate an external identity provider and then decide that loosely coupled, eventually consistent is the right choice. Instead developers mostly just choose whatever seems sufficiently popular and build their system around it and only look somewhere else if the popular choice is visibly much worse at its job than the alternatives. ("visibly" with the knowledge about the topic at hand that is. Most people I've talked to just see OIDC flows as a given fact about how authentication has to work.)

From a practical perspective, there are lots of applications out there which are perfectly reachable from the outside and which use an OAuth2/OIDC library as a standard component where they could forward an update from the identity provider with a simple library call. And think about how much edge cases in front-end applications could eliminate, if you wouldn't have to be ready to get a new token at any moment, because the current one has just expired. [1]

In my opinion, pushing updates to clients should be the default of identity protocols which you only opt-out of, if you have special needs. And then hopefully documentation tells you very clearly to have very short token expirations.

[1] And yes, you technically still have to be prepared for that at any time, but you can push the trade-off of making that case less user friendly much further, if it occurs only seldom.

Re: Short session expiration does not help security

#188
> If an attacker steals a session cookie with XSS or session fixation, the attacker immediately gains access to a valid session and can keep performing requests to keep the session alive.

Objectively false? If they get the refresh token sure, but even that has an expiration and isn't refreshable in many common implementations.

If they only get the access token, then this is completely false; you can't refresh a session using only the access token.

Re: Short session expiration does not help security

#189
post #19
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…

The author also puts lot’s of faith on the user not doing stupid things: “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, no matter how short the session expiry time is.” Yeah, users might just leave their bank logged in a open and logged computer library. That’s why short sessions exist for those as th…

It's better to let users do stupid things so they learn from their mistakes and not do them ever again. And probably tell their story to their friends and family so they, too, don't do this. Putting all these excessive guards in place kinda encourages ignorance and tech illiteracy.

Re: Short session expiration does not help security

#190
post #177

Earlier quoted context omitted.

> dozens of randomly generated authentication pages I have never seen an authentication page be randomly generated. Elaborate?

I'm explaining it poorly; think about the urls for common authentication redirects and how it usually looks when you go through an SSO portal. Probably you start at a page like: sso.company.com When you try to access a service, you're taken to probably something like sso.company.com/auth If your company uses Microsoft or Gmail, very likely before you reach your SSO login, it may temporarily flash MS/Google's auth pag…

Some Lastpass admin page redirects me no joke like 10 times.
Post reply on HN