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

151–160 of 434 posts

Re: Short session expiration does not help security

#151

Post by thayne »

WhitneyLand wrote: post #89

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.

Security is more my focus than UX (although I am not myself a "security professional"), and I neither agree nor disagree with the thesis of the article. I think the right answer is the classic "it depends". Specifically, it depends on how bad it would be if a session token is leaked, how the rest of the authentication system works (can session tokens be revoked, what is required to refresh a token, how long is the absolute expiration of a token, etc.), and even whether the user is using a public computer or not.

That said, the arguments in this article makes many dangerous assumptions. Such as assuming that users never use a shared computer (like say the computer in a library), and that you can completely reliably avoid tokens from ever accidentally getting logged.

Re: Short session expiration does not help security

#152

Post by rrrpfb11 »

nidble wrote: post #71
irrational wrote: post #53

I use one website semi regularly that has what feels like a 5 minute session expiration, but is actually probably 10 minutes. The session expires even if you are actively using it. Drives me nuts. But not nuts enough to write in and complain. Maybe I should send them this article ;-)

Let me guess... is it a bank? One of mine's does it (expires session after a few minutes, even actively using it). I find that bank websites usually follow completely opposite ways regarding to security than any other industry: very short passwords, only digits, not encrypted in db (some sites ask for single positions), mandatory password input by virtual keyboard, cannot use password managers, not using 2FA or only…

Re single positions, my bank requires a password (which one hopes is appropriately hashed and so forth) plus a challenge to supply requested offsets into a secret phrase. That mitigates I suppose against over the shoulder attack. And they have fewer requirements of the phrase so maybe it’s less likely to be written down?

I’m curious whether there’s a technical means to allow the challenge by offset without storing the phrase plain text. I’m challenged for four positions - in theory it could store hashes of all possible four offsets, but is there a better way?

Re: Short session expiration does not help security

#153

Post by GoblinSlayer »

datadrivenangel wrote: post #98
BillinghamJ wrote: post #12

Earlier quoted context omitted.

On all their websites. Microsoft is quite a bad offender of this also.

Microsoft is the worst. Endless auth redirects, and gates help you if you've ever had multiple microsoft accounts on the same device.

Dunno, skype asked my password a long time ago.

Re: Short session expiration does not help security

#155

Post by paulddraper »

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…

> 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 already give you access far beyond that session itself

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

Re: Short session expiration does not help security

#156

Post by sneak »

logicalmonster wrote: post #148

Just to play Devil's Advocate, short sessions may actually end up being far less secure when you consider that humans are flawed. If you force people to log in to a system very frequently, they might get lax with security and do dumb things like stick "post-it notes" to their monitors with their login info out of frustration.

Device malware, which is common, can't steal those.

Re: Short session expiration does not help security

#157

Post by paulddraper »

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

> dozens of randomly generated authentication pages

I have never seen an authentication page be randomly generated.

Elaborate?

Re: Short session expiration does not help security

#158

Post by GoblinSlayer »

WhitneyLand wrote: post #89

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.

Short timeout is neither security nor UX, it's security theater to cover the owner's ass when something happens.

Re: Short session expiration does not help security

#159

Post by obblekk »

@sama

Jk though I intuitively agree, I think this article doesn't really prove its claim.

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

I would argue shared computers are one of the primary threats deterred by this.

Additionally, for the attacker has access to device section, the author points out an attacker could still access email. But, email services tend to be more developed and often have the ability to expire all tokens (or logout all browsers). The exact place short session expiration helps is when the service does not provide a feature to log out all sessions remotely. That would be a better deterrent by far, but may be more complex to build than a default timeout.

Re: Short session expiration does not help security

#160

Post by cj »

ahtihn wrote: post #140
cj wrote: post #50

Earlier quoted context omitted.

The idea of “adaptive security” is compelling. E.g. my bank makes me type my password and sends 2fa codes when initiating/approving wire transfers… even when I just logged in a minute ago. If I’m doing 2 wire transfers in a row, it doesn’t care, it still has me fully reauthenticate for every wire transfer. But I’m fine with that because moving money is something that I’m willing to accept however many roadblocks are…

> But I’m fine with that because moving money is something that I’m willing to accept however many roadblocks are thrown at me. Really? I'd change banks over that. If I log into my e-banking website, the main activity I'm going to do is pay bills. I would absolutely not tolerate having to jump through hoops to do it.

This is our business account so we're moving anywhere from $20k to $200k at a time.

In the spirit of adaptive security, someone moving $100k will probably be fine dealing with a couple extra password / 2fa prompts... but I agree it would be annoying to deal with this for day-to-day (consumer) bill pay. A bank could throw fewer roadblocks when paying a $500 invoice vs. a $50,000 invoice

The workflow I described also is part of a dual-approval model where a finance person sets up the transfer and it's approved by a 2nd person (who's presented with a bunch of authentication/password/2fa prompts, almost to a fault).

But again, I'm fine with it because it's large amounts of money in corporate bank accounts. But yea, agreed it would be annoying and should be toned down in a consumer use case.

Post reply on HN