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

251–260 of 434 posts

Re: Short session expiration does not help security

#251

Post by kccqzy »

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…

Why wouldn't the system require each refresh of the session token to require additional authentication? Then a stolen token can't easily be refreshed.

Re: Short session expiration does not help security

#252

Post by marcus0x62 »

iudqnolq wrote: post #216
marcus0x62 wrote: post #132

Earlier quoted context omitted.

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

How likely is it for an attacker to get access to the user's cookie jar at a single instant in time only? > There are instances where session timeouts/forced reauth are useful and where an attacker could not endlessly refresh the token. If the token isn't refreshable without a "real token" the "real token" will probably need to be somewhere the attacker can get it anyway.

> How likely is it for an attacker to get access to the user's cookie jar at a single instant in time only?

Depends on the dwell time the attacker has until detection and eviction, but generally speaking, in the scenario where session tokens are being harvested from a user’s workstation or something like a jump server, the attacker is going to be able to access stored session tokens from the most recent login prior to their gaining access and any that occur during access. In any case, shorter session tokens are going to result in less access for the attacker. There isn’t a scenario that results in more access, and only absurdly contrived scenarios that result in the same access.

> If the token isn't refreshable without a "real token" the "real token" will probably need to be somewhere the attacker can get it anyway.

That may be true of ticket-granting-ticket schemes, but not for single/multifactor authentication for ticket schemes. Both scenarios exist and need to be accounted for appropriately.

Re: Short session expiration does not help security

#253

Post by generalizations »

vuln wrote: post #229
oceanplexian wrote: post #222

Earlier quoted context omitted.

The other thing security people fail to realize is that when you’re hostile to UX, people start coming up with all sorts of workarounds that leave you less secure than you were before. Like the corporate managed laptop is so full of spyware that users bypass it and use their own personal device for development.

We don’t fail to realize that. Security folks are humans too. We realize that every human loves convenience and security removes conveniences. Simple As. No matter what we do as security folks, the users will do everything possible to return to their convenience or complain about the inconvenience until the security is removed. I’m not saying there aren’t over zealous security folk but our goal isn’t to make humans l…

> human loves convenience

Except that it's not a matter of 'convenience', it's a matter of being able to do their jobs. Security is a hard job, in part because you have to come up with security practices that are actually workable, and keep work impediments to a minimum. It's really easy to just add more restrictions. It's hard to add security that doesn't impede the users. When I see 'defense in depth' being invoked to justify massive work impediments for minimal security improvements, I don't see effective security practices - I see a cargo cult.

Re: Short session expiration does not help security

#254

Post by imachine1980_ »

vuln wrote: post #229
oceanplexian wrote: post #222

Earlier quoted context omitted.

The other thing security people fail to realize is that when you’re hostile to UX, people start coming up with all sorts of workarounds that leave you less secure than you were before. Like the corporate managed laptop is so full of spyware that users bypass it and use their own personal device for development.

We don’t fail to realize that. Security folks are humans too. We realize that every human loves convenience and security removes conveniences. Simple As. No matter what we do as security folks, the users will do everything possible to return to their convenience or complain about the inconvenience until the security is removed. I’m not saying there aren’t over zealous security folk but our goal isn’t to make humans l…

not your objective is make the organización loss the less money posible by reducing the incident rate the recovery rate or the impact if you damage the org more the risk you are saving against you are liability, this isn't good vs bad thing, this is decide when the line is worth crossing and this article say at least in their opinion this open isn't, you still have multiple other layers.

Re: Short session expiration does not help security

#255

Post by vel0city »

godshatter wrote: post #238
vel0city wrote: post #70

Earlier quoted context omitted.

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.

Systems like that probably do have some form of plain text password history which is very wrong. They might also do some basic common transforms of the password (Increment the numbers, did the hash match? Decrement the numbers, did the password match? Swap case around, did the password match?) but I do agree that's probably a pretty big stretch versus taking the easier (and worse) way to make that anti-feature.

I'm not saying that everyone does it right, I'm just saying having a password history enforcement does not require them to keep plaintext passwords. You don't need to "keep everyone’s password and previous password around in a database" in order to have some form of password history enforcement.

Re: Short session expiration does not help security

#256

Post by grishka »

Zetice wrote: post #242
grishka wrote: post #227

Earlier quoted context omitted.

In what kind of situation would logs be the only thing a malicious actor could access? If they exploited the application that writes them, then they have as much access as the application has — and if its job includes creating access tokens, it definitely has access to the database that stores user accounts.

Happens all the time , where access is through a low privilege user, or the nature of the infiltration isn't just a user but through some specific tool that only itself has access to specific things. Maybe the hack gets you into Splunk and that's it, and only for a few hours because the session you hijacked expires... Nobody exposes access tokens on purpose, there is no "its job includes creating access tokens". No s…

> In a JWT, the token is signed and you validate the signature with a cert, and that cert is public knowledge.

JWT is a particular type of token. Not everyone uses JWTs because they have drawbacks — in particular, a self-contained signed token can't be revoked without maintaining some sort of blacklist of invalidated tokens. So you have to resort to expiration to make up for that I guess?

In my own backend projects I use session IDs that are simply long random strings that are stored in the database. I delete the row when the user logs out of their session.

Re: Short session expiration does not help security

#257

Post by bmurphy1976 »

nine_k wrote: post #226
bmurphy1976 wrote: post #206

Earlier quoted context omitted.

That's a nightmare process for any normal user. There's no way the vast majority of people are savvy enough to do this correctly.

Which part of the "click print, cut or rip out a corner, put it in your wallet" a nightmare for a normal user? (I'm not one, can't judge.)

The part where you actually have to do it. And the part where you remember where you put it. What happens when you lose your wallet? Or when the paper gets crumped up and ruined? Or wet? Do they put it in a lock box? What good does that do them when they are in another country? What if they reset their password and have to reset their codes but forget to update the paper? Or what about when you have the old and new codes and can't remember which piece of paper you put on top? How may of them actually go back and verify that the codes work and the process hasn't changed and they can successfully recover their accounts? How about the 50 other accounts they have all forcing their unique and totally different 2FA recovery process that isn't like any of the others?

I keep my backup codes in a GPG encoded document with copies of it in multiple places. It's a big pain in the ass but I know I'm covered. For the vast vast majority of people this is more theatrical bullshit they won't bother with.

Re: Short session expiration does not help security

#258

Post by marcus0x62 »

kccqzy wrote: post #251
TeMPOraL wrote: post #61

Earlier quoted context omitted.

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

Why wouldn't the system require each refresh of the session token to require additional authentication? Then a stolen token can't easily be refreshed.

UX for common applications is poor. Would you want to have to enter your email password every hour or two, for instance?

I’d argue for truly critical infrastructure, short-ish session times can be useful, but for most applications they do more harm than good and better alternatives exist. For instance:

* Enforcing step-up authentication for access to sensitive application functions.

* Forcing re-auth based on behavioral analytics (for instance, if the user normally accesses an app 8 - 5 Monday - Friday from the United States, but presents a session token on Saturday afternoon from Russia, maybe force a reauth.)

* For enterprise apps, SSO where you may be forcing an authentication event every shift, but at least it is one, not one per app.

But, of course, there is no one right answer because there is no universally applicable or agreed upon threat model.

Re: Short session expiration does not help security

#259

Post by paulddraper »

horsawlarway wrote: post #240
paulddraper wrote: post #155

Earlier quoted context omitted.

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

> theft is that it also immediately alerts the user

The user may or may not know of theft or leak.

And even if they are aware, they may not know remember every remote system they were logged into.

> Rotate it after 30 days if you want (or 5 days, or 1 day - just don't do it every 15 minutes).

So we've gone from arguing that short sessions doesn't work, to arguing that it works for such a large % of the cases that it could be relaxed.

Re: Short session expiration does not help security

#260

Post by marcus0x62 »

hinkley wrote: post #247
water9 wrote: post #56

Earlier quoted context omitted.

Once the attacker knows they can steal the session ID, and how long it will be valid for. It’s just a matter of running a script to do that all that as fast as possible.

I will posit this proposition: Short sessions are thinking like physical security. Someone can pick any lock, the question is will it take long enough for a human to interrupt the attack? It doesn’t matter how long a computer has access to the key. How fast it can cause damage is limited by the speed of light, not human fingers. If you ever leave the credentials where they are accessible, they can be used even if the…

> Machines hack differently than humans.

An awful lot of hacking is done manually, by humans. For many scenarios, considering human timeframes is completely reasonable.

Post reply on HN