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

231–240 of 434 posts

Re: Short session expiration does not help security

#231

Post by [deleted] »

vel0city wrote: post #62
_tk_ wrote: post #5

Hand waving away the threat of application use on shared devices seems a little over confident to me. This is probably not a threat for company devices, but it is clearly a threat in other environments, i.e family members sharing a device. While some users might expect to be logged in all the time, others expect to be logged out after they close a web app tab. Session expiration should be application specific. Google…

> Google's sessions do not expire They kind of do. I use a lot of machines that I might only hop on once a month or so. Chrome sync often ends up in a "paused" state where I have to re-auth. YouTube will fall back to a not-signed-in profile on me and I'll need to re-auth every now and then. Loading up Gmail will have me re-auth again pretty often. Often its not a full re-auth with my security keys but it'll at least…

[deleted]

Re: Short session expiration does not help security

#232

Post by horsawlarway »

pxc wrote: post #194
jameshart wrote: post #83

Earlier quoted context omitted.

> This attitude is cancer > yes really - fucking always You're really angry with that straw man you've stood up. The OP isn't saying systems have to be locked down to the extent that they're useless. Who would ever argue for such a thing? 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 secur…

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

Re: Short session expiration does not help security

#233

Post by computerfriend »

adrr wrote: post #39

Browsers need to provide a way for sites to query if the device has a pass code or not. The lost device threat is a top reason for short session cookies.

If you control the device you can spoof whether it requires a passcode or not. Unless you go down the user-hostile rabbit hole of device attestation.

Re: Short session expiration does not help security

#234

Post by GoblinSlayer »

hannasanarion wrote: post #207
GoblinSlayer wrote: post #128

Earlier quoted context omitted.

If the attackers control user machine they will have as much information as the user anyway.

Not if they don't have the passwords and 2FA devices to access company resources from that machine, and all of the sessions are expired.

If all sessions expired, then the user doesn't have access to information either - same access as the attacker. There are cached copies of emails too.

Re: Short session expiration does not help security

#235

Post by unethical_ban »

Short aside about session lengths:

If you are an app like Chase or Discover, and you intend to kill my app's biometric auth session after say 90 days, please tell me that when I first login manually and at least 7 days before said session will end.

I keep my passwords in local password safes, and I manually sync a copy to my phone.

It should not be expected by the user to have access to their passwords every day, if they have apps which say "Oh yeah, fingerprints! We trust you!".

If I were in the middle of a trip and got logged out of my mobile app without my password safe, I would be screwed, and it would not be my fault, given how opaque the session policy is on these apps.

Re: Short session expiration does not help security

#236

Post by skinner927 »

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…

Do you sign a request with that reauth token or do you send the reauth token? Because if they’re getting mitm then all is lost. How long does the reauth token last for? Is a new one issued when you reauth?

As negative as I sound, the system is better than just allowing the regular api token to extend the session. Of the hundreds to thousands of api requests a regular user may make a day, only 1 is the reauth, which is nice.

Security is an onion. Every layer is a bit sour and eventually you’ll cry.

Re: Short session expiration does not help security

#237

Post by ozim »

grishka wrote: post #219
Zetice wrote: post #213

Earlier quoted context omitted.

Hacker gets in, exfiltrates your log files that mistakenly have session tokens in them, goes through over the course of an hour or two before stumbling upon an admin session token that's still valid apparently. Could easily write a script to find the session tokens and check them for validity. Many have their TTLs directly embedded, no need to touch a server to check, at least for that.

If a hacker is able to exfiltrate log files, what's to prevent them from exfiltrating other things? If they get into a server, they could as well dump sensitive data form the database or do something to gain persistence, like installing a shell or adding their SSH key. If they get into a client device, they could steal more, more valuable data than just some logs — browser cookies, email credentials, app tokens, owne…

Have to disagree. Lots of times it is only opportunity to get logs from some misconfigured instance of elastic or some other log aggregation system or read only somewhere on web server. Without possibility to own the whole system.

Re: Short session expiration does not help security

#238

Post by godshatter »

vel0city wrote: post #70
gabereiser wrote: post #36

Neither does “Your password cannot match your previous 1,000 passwords”. Let’s just keep everyone’s password and previous password around in a database shall we?

You don't need to keep someone's plaintext password in the database to compare. Just re-calculate hashes against historical hashes at new password time. If the hashing process is secure keeping a few old hashes isn't really a security concern, especially if people are actually using unique passwords. Now, normally this is tied to an automatic password rotation policy, because allowing a previous password completely u…

I have seen sites that complain if your password is too similar to a previous password, and that shouldn't be possible with hashes. So who knows of the sites that look for exact matches are looking at the hashes or not.

Re: Short session expiration does not help security

#239

Post by jedberg »

skinner927 wrote: post #236
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…

Do you sign a request with that reauth token or do you send the reauth token? Because if they’re getting mitm then all is lost. How long does the reauth token last for? Is a new one issued when you reauth? As negative as I sound, the system is better than just allowing the regular api token to extend the session. Of the hundreds to thousands of api requests a regular user may make a day, only 1 is the reauth, which i…

> Do you sign a request with that reauth token or do you send the reauth token?

Sign

> Because if they’re getting mitm then all is lost.

This is true regardless of your authentication scheme, which is why https is important and then you have to hope they didn't just click through a warning and ignore it or have their trust store compromised or....

> How long does the reauth token last for?

Until it is reissued. But since the auth token is only good for 12 hours, effectively 12 hours max, since it can't be used for reauth without a valid auth token.

> Is a new one issued when you reauth?

Yes.

Re: Short session expiration does not help security

#240

Post by horsawlarway »

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…

> For the local system, yes. But not the for the remote system.

This is fair, although you've picked a specific case where the local system would not likely access the remote system again after compromise (because theft removes access for the normal user) and an expired session might be helpful as security.

But the other thing about theft is that it also immediately alerts the user, and having a simple "Sign me out everywhere" button is a more robust solution that causes much less user pain and mostly accomplishes the same result.

As for

> one minute to one year from now.

I'm not arguing for indefinite sessions. I'm arguing against short sessions. Rotate it after 30 days if you want (or 5 days, or 1 day - just don't do it every 15 minutes). It'll catch 99% of the cases you're thinking about solving, and it's literally 3000 times less annoying for your users while being nearly as secure.

Post reply on HN