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

81–90 of 434 posts

Re: Short session expiration does not help security

#81

Post by vidarh »

horsawlarway wrote: post #26
dakial1 wrote: post #19

Earlier quoted context omitted.

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…

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

> I'll just run a keylogger

You could. But what is relevant is whether you have. The point is not to protect against a determined attacker, but to reduce the chance of an opportunistic attack.

It really feels like most people have little experience with shared computer resources any more, because pranking people who left their computer unlocked used to be practically a sport, even when the same people would (mostly) never go out of their way to attack a locked down account.

Screen locks became a thing long before mobile devices for a reason.

Re: Short session expiration does not help security

#82

Post by cuu508 »

horsawlarway wrote: post #26
dakial1 wrote: post #19

Earlier quoted context omitted.

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…

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

Re: Short session expiration does not help security

#83

Post by jameshart »

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…

> 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 security gap and compromised usability".

Be charitable in your interpretation. Your OP is making a simple argument that defense in depth is a part of a security posture, precisely because they agree with your core premise, that security is always a tradeoff. Because we won't choose to implement every security measure, and because the security measures we do implement will be flawed, or compromised by the need for the application to actually be usable.

Step outside, breathe some fresh air, maybe lay off the coffee first thing. And consider not throwing 'cancer' bombs at passers-by.

Re: Short session expiration does not help security

#84

Post by eli »

GoblinSlayer wrote: post #30
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…

Librewolf has an option to delete cookies on exit. Then you are as secure as possible.

Pretty sure every browser does

Re: Short session expiration does not help security

#85

Post by throwaway03626 »

rspeele wrote: post #76
allanbreyes wrote: post #40

Earlier quoted context omitted.

NIST dropped the password change recommendation a while back [1] but it still lingers on. The staying power and long tail of this deprecated advice is unfortunate, to say the least. I don't personally agree that short sessions is bad advice, but Phil Venables has an article that you might enjoy, "Ceremonial Security and Cargo Cults" [2] [1] https://pages.nist.gov/800-63-FAQ/#q-b05 [2] https://www.philvenables.com/pos…

My experience with security auditors from big firms is that they have a checklist including recommendations like 90-day password changes, composition rules, and so on, and will probably never get rid of those. You may be able to explain to the assessor that "we don't force password changes because NIST no longer recommends it", and they may be sympathetic, but they are still ultimately going to deliver a report that…

Reminds me of the anti virus software at work many years ago that did not allow me to download a password encoding library, because the filename contained the word "password"

I've also experienced automatic security reports that complain that the configuration file contains the word "password" (as in "database.password="). I had to argue with them that we did not actually store passwords in Git as they could clearly see, but that it was set using a environment variable by a secrets manager when actually running in a container. Next time we had a similar use case we would just give it a different name to avoid this complication

Re: Short session expiration does not help security

#86

Post by eli »

bombcar wrote: post #45

The proper way to handle the problem is to tie session IDs to more than just a cookie or other fixed value; so that if they get exfiltrated they cannot be used without reauthenticating. For example, the Session ID becomes "IP address + session token + browser ID" or something, then if I get your token, and even if I can mimic your browser fingerprint, I'd still have to be coming from your IP.

This is going to fail and break sessions for users way way more often than it's going to stop a bad guy

Re: Short session expiration does not help security

#88

Post by jabroni_salad »

ideksec wrote: post #29

This article makes so many unfounded assumptions in order to make a point. > Presumably they are going to immediately make themselves admin, or wire all your bitcoin to their account. Attackers running scams like a sophisticated BEC will lay dormant for long stretches of time to gather information before acting. Sure, they can export the emails and set up auto-forward rules to maintain visibility when the session exp…

I recently had a BEC on my desk where they had gained access months earlier to a real estate agent's mailbox. They took the time to create perfect forged documents and understand the agent's workflow. Finally it was time to tell a buyer where to send their Earnest Money and the actions were perfect. They made a mail rule that captured the RE agent's outbound message and then sent their own, an exact replica with just the account number changed. Even if the buyer had called to verify the message it would have been fine because the agent really did send a message.

Of course finance people are used to stuff taking an arbitrarily long time (partly the users, partly the system) so they were able to do this several times before anyone raised the issue of MIA transfers.

Oh and we don't know the exact date of the compromise because the customer was not paying for good log retention from microsoft or exporting them to any kind of collector. We were able to uncover a lot but I wonder how this goes for indy RE agents that do everything out of AOL or whatever.

Re: Short session expiration does not help security

#89

Post by WhitneyLand »

This one seems prone to bias.

Out of all the people disagreeing in the comments who actually takes a position against self interest?

1) Security is more your focus than UX, but you agree with the article.

2) UX is more your focus than security, but you disagree with the article.

Re: Short session expiration does not help security

#90

Post by generalizations »

jameshart wrote: post #83
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…

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

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 down systems to the point of uselessness, without actually, technically, preventing work from being done.

Post reply on HN