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

161–170 of 434 posts

Re: Short session expiration does not help security

#161

Post by _8j50 »

I agree with the author but I would add "... but long session expirarion harms security".

In the real world, if an infostealer is stealing your session cookies, it doesn't have to be a one time thing,it can send your cookies back on an interval.

But speaking of, ssh private keys and user auth certs having an overly long lifetime is as much of an issue. SSH is the worst offender but for the unaware, you can enroll a cert for a windows account and even if the password is rotated regularly (like your super secure hashicorp/cyberark/tychotic rotated service account) that one cert can be used to get kerberos tickets and login/auth just fine, the cert lifetime is usually months if not years. Smarter folks use a CA with SSH but the thing with CAs is you must use ocsp responder for short lived certs because a CRL isn't always feasible, maintaining ocsp for this type of frequent use at scale is no simple matter either.

Back to web sessions though, in the cloud and on azuread/o365 stuff (like onedrive or teams), the session token does get renewed every few hours but without any user interaction because the device is trusted. So all a threat actor needs is one sesssion/token and the ability to proxy traffic through the victim host. Matter of fact, my secret yet controversial opinion is that SSO should never be implemented without 2FA period. No exceptions! The cred you manage centrally gets also pwned centrally. A lot of crap like device auth and conditional access policies make SSO very dangerous, if I had a company I would mandate yubikeys and password managers with app specific creds by default and SSO with yubikey where possible. With 1 day expiration as a default.

Re: Short session expiration does not help security

#162

Post by jedberg »

They way I like to handle session tokens that seems like a good compromise between security and user friendliness: Automatically renew the token as long as the user is actively using the website. I usually use a 12 hour token and renew if it's 8 hours old or more. The renewal requires the use a second token stored locally in the browser so even if you somehow sniff the token off the wire, you still can't renew it without control of the user's browser.

And frankly if they have control of the user's browser, they could probably install a key logger anyway.

That way, if someone is constantly using the site, they would never notice a logout, but otherwise they might have to login once a day.

Re: Short session expiration does not help security

#163

Post by nine_k »

csydas wrote: post #149
horsawlarway wrote: post #93

Earlier quoted context omitted.

This is just wrong on so many levels. > A short token forces the $1000 withdraw immediately. No, a short token forces the attacker to continue making requests, but otherwise places very few limits on what they can do with it (since these tokens are almost always something like "15 minutes since the last use") > In your ship analogy, that's adding a second hull, putting airtight sections between hull locations, and ha…

>There is a cost every time a user has to re-authenticate. There is a cost in resources to handle the extra authentications. There is a cost in complexity to maintain and extend the system doing authentication. I think this is definitely where the security trends in modern IT have gone very awry, as it _is_ extremely annoying to be an end user having to work with modern IT security practices. Off the top of my head:…

> if you have any issues with your alternative authentication devices, you are completely locked out of your work

You have printed the rescue codes when prompted, and have put that physical piece of paper into your wallet, haven't you?

Re: Short session expiration does not help security

#164

Post by ilyt »

paulddraper wrote: post #155
horsawlarway wrote: post #18

Earlier quoted context omitted.

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

> A short compromised session is still a compromised session. The duration usually does not prevent the attacker from achieving their goal. Why "usually does not"? The stolen hard drive, leaked data, etc. can happen at any point in the future....one minute to one year from now. For most of those times, a short session will prevent the attacker from exploiting it. > The vast majority of ways to compromise a session al…

Stolen hard drive is rarely what you defend from, and arguably might completely not matter if say their short lived session is dead but long-lived password manager one is up.

Exploits owning software on machine are far more common than machine itself being stolen.

I'd also argue that tying re-login to the sensitive actions is far better way to fight it. Basically have long session for nondestructive actions but short for any potentially harmful ones like changing payment options.

Re: Short session expiration does not help security

#165

Post by horsawlarway »

rrrpfb11 wrote: post #137
horsawlarway wrote: post #18

Earlier quoted context omitted.

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

> I’m not trading anything off that I’m aware of.

Really? Really???? You're not, say... having to manage ACLs, and having to run a system that can enforce ACLs?

Because both of those are tradeoffs. They might be "completely sane and reasonable" tradeoffs! But they are still tradeoffs.

Also - in a more blunt way: Simply not being able to see other peoples files was considered a pretty big negative in some computing crowds when it was first enforced. That's a huge tradeoff: You're sacrificing visibility for privacy.

I think that turned out to be the correct tradeoff in most places - but to be clear - you absolutely are losing a feature to gain a feature.

Re: Short session expiration does not help security

#166

Post by ryanianian »

Killing short sessions would be somewhat nice from a user perspective, but I think this is unrealistic as others point out. Instead, let's focus on what makes short sessions super obnoxious.

In theory I don't mind a fast and painless re-auth that doesn't hugely interrupt my flow. But the current implementations seem to be actively user-hostile and intentionally annoying.

My company has moved to Okta for most things. Fine. But the session expiration and re-auth mechanism is extremely maddening. It comes out of nowhere.

Right in the middle of doing work, I need to re-auth to {jira, github, google suite, whatever} without any warning. Github in particular makes you re-auth to each org independently even if trying to view OSS material that doesn't require auth to begin with.

And of course SSO flows break anchor tags in URLs so good luck if you already closed the link that had the necessary anchor information.

Then let's talk about Okta in particular requiring three separate pages and clicks for user, pass, otp (because a single form with all three is "insecure" in a meaningful way?). And then not respecting dark mode making an otherwise dark-friendly workflow have flashes of bright light at unpredictable times.

Sure, let's make regular re-auth a thing. I'd even do it once every X hours. But come on.

Let's make the re-auth schedule predictable (ugh google suite re-auth right in the middle of screen-sharing or doing deep work on a doc).

Let me pre-emptively re-auth everywhere all at once in a batch (pointing my finger at you, github).

Let's figure out a way to preserve anchor tags (javascript is a thing, sso sites could capture and sso providers could pass this through).

And dear god, Okta, please just support dark mode on your interstitials. I view that bright flash of light about 5 times per day now and it raises my cortisol levels and hurts my eyes every time.

I know TFA isn't about SSO flows, but SSO flows + short sessions highlight how annoying the end-result of this hodge-podge of auth is for users trying to do their job.

Re: Short session expiration does not help security

#167

Post by neolefty »

theresmoretoit wrote: post #6

https://learn.microsoft.com/en-us/azure/active-directory/con... Those “sessions which never expire” do, in fact, expire. It’s just that there’s more to it than time. The author should read up on the reasoning behind primary refresh tokens and session tokens.

They also expire faster when suspicious things happen, such as your IP address changing. Auth providers are pretty quiet about what they find "suspicious" — some are obvious, some are clever.

Re: Short session expiration does not help security

#168

Post by neolefty »

jedberg wrote: post #162

They way I like to handle session tokens that seems like a good compromise between security and user friendliness: Automatically renew the token as long as the user is actively using the website. I usually use a 12 hour token and renew if it's 8 hours old or more. The renewal requires the use a second token stored locally in the browser so even if you somehow sniff the token off the wire, you still can't renew it wit…

Some big auth providers throw in a few extra signals too. Your IP address changes? That might hurry up expiration a little. Your user agent changes? Big red flag. Etc.

Re: Short session expiration does not help security

#169

Post by [deleted] »

horsawlarway wrote: post #138
cuu508 wrote: post #82

Earlier quoted context omitted.

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.

[deleted]
Post reply on HN