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

321–330 of 434 posts

Re: Short session expiration does not help security

#321

Post by chongli »

Nextgrid wrote: post #21

In a lot of cases, short session expiry is used as a hack around subpar authentication standards such as SAML/OIDC where there is no reliable backchannel for the identity provider to tell the service to expire sessions (following a credential change, user being deleted, etc). The short session expiry is used as a workaround to force the third-party service to regularly check-in with the identity provider, thus placin…

How would those other technologies deal with the situation where grandma signs into her banking account via app on her phone and then gets distracted, leaving her phone unlocked on the table for teenage Jimmy to find? My bank uses short sessions so I get signed out within a few minutes of inactivity. Long sessions would seem to leave grandma wide open to this sort of local attack.

Re: Short session expiration does not help security

#323

Post by deepsun »

plorntus wrote: post #307
ljm wrote: post #286

Earlier quoted context omitted.

My main bank uses username + password + (random subset of ‘memorable word but actually unencrypted password’ driven by select boxes), then 2FA on top, and it literally feels like they just slapped a bunch of things together to add extra barriers to auth in sequence. This is the UK. Back in Latvia I would just slide my ID card into a USB reader and cryptographically sign the session with a passcode. Same as chip & pin…

Spains banks (I’ve used two so far) simply use your ID number which is used in a lot of places and not considered secret and enforces a 4 digit password. It’s an absolute joke.

Bank Of America requires to tell them a 2FA code sent over SMS, when SMS literally says:

   BofA: DO NOT share this code. We will NEVER call you or text you for it.
No, it wasn't scam, seen that process physically visiting a branch on agent's display multiple times.

Re: Short session expiration does not help security

#324

Post by DylanSp »

paulddraper wrote: post #144

> Perhaps you used the shared computer in the library to access your web application, and forgot to log out. > 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. Yes, it is a thing. I understand you would like it to not be a thing.

The article bringing up that scenario and immediately dismissing it actually convinced me to change my opinion to the opposite of the article's thesis. I generally haven't seen the need for short session expirations in the past (when I've thought about it, which isn't often), but I hadn't thought about the shared-computer scenario before. Keeping that in mind, and knowing that it can't be handwaved away (as you point out), short sessions make more sense to me now.

Re: Short session expiration does not help security

#325

Post by littlestymaar »

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…

> Security is ALWAYS (fucking always, yes really - fucking always) a tradeoff.

> The most secure application runs completely isolated, with no input or output, and is totally, utterly useless. But no worries - it's secure!

Yeah, as the Rust saying goes “The safest code is code that doesn't compile”

Re: Short session expiration does not help security

#326

Post by kyle-rb »

Zetice wrote: post #185
jmull wrote: post #114

Earlier quoted context omitted.

Hang on, we're talking about user sessions and you're talking about access tokens. Short expiration of sessions is bad because of the terrible UX. Access tokens can be refreshed without user interaction, so it's not the same issue there.

"Session" here is the word used for the duration in which an access token is valid. You may be talking about UX, but the submission is talking about access tokens.

The article specifically mentions the need for users to re-enter their username and password as a downside of short-lived sessions, so I think the author's definition of "session" extends as long as the refresh token lasts.

I think that most of the non-short-session examples — Google, Microsoft, GitHub, etc — are using an access token + refresh token pattern.

Re: Short session expiration does not help security

#327

Post by jperras »

Fatnino wrote: post #320
actuallyalys wrote: post #186

The main place I see short session expirations is on banking and financial apps, which seems defensible to me for a couple of reasons: 1) They're used by a wide variety of people, including people who may not own a computer or mobile device, or who may not have a backup device to use when their personal device breaks. This group is probably shrinking—more and more people have smartphones and the remaining people who…

There is a class of people who feel a smartphone is too much of a distraction to carry around all the time. They will carry around a flip phone that can do basically nothing beyond calls, sms, and camera. These are otherwise perfectly normal members of society with bank accounts. I don't know how common these people are. I happen to know a handful of them but I probably don't travel in typical circles.

I live in a very Hasidic Jewish neighbourhood in North America; they (almost) uniquely use flip phones instead of smart phones.

I've even seen women with cordless landline phones mounted to their shpitzel so that they can use it "hands-free", but without breaking their rules around kosher technology.

Some context:

https://www.theguardian.com/world/2022/jul/19/kosher-phone-d...

Re: Short session expiration does not help security

#328

Post by Zetice »

kyle-rb wrote: post #326
Zetice wrote: post #185

Earlier quoted context omitted.

"Session" here is the word used for the duration in which an access token is valid. You may be talking about UX, but the submission is talking about access tokens.

The article specifically mentions the need for users to re-enter their username and password as a downside of short-lived sessions, so I think the author's definition of "session" extends as long as the refresh token lasts. I think that most of the non-short-session examples — Google, Microsoft, GitHub, etc — are using an access token + refresh token pattern.

That's because it's a poorly written article by someone who doesn't know the difference. It interchangeably talks about issues only with the UX and the actual technical backend pieces involved.

Re: Short session expiration does not help security

#329

Post by illusiveman »

plorntus wrote: post #307
ljm wrote: post #286

Earlier quoted context omitted.

My main bank uses username + password + (random subset of ‘memorable word but actually unencrypted password’ driven by select boxes), then 2FA on top, and it literally feels like they just slapped a bunch of things together to add extra barriers to auth in sequence. This is the UK. Back in Latvia I would just slide my ID card into a USB reader and cryptographically sign the session with a passcode. Same as chip & pin…

Spains banks (I’ve used two so far) simply use your ID number which is used in a lot of places and not considered secret and enforces a 4 digit password. It’s an absolute joke.

I wondered once about this, but it kind of make sense from the point of view of usability.

Unlike any webservice, you usually have very few attempts to make a successful login before getting locked out, so even if it's four digits, the odds of a successful brute force attack are very low

Re: Short session expiration does not help security

#330

Post by ljm »

jrockway wrote: post #318
ljm wrote: post #286

Earlier quoted context omitted.

My main bank uses username + password + (random subset of ‘memorable word but actually unencrypted password’ driven by select boxes), then 2FA on top, and it literally feels like they just slapped a bunch of things together to add extra barriers to auth in sequence. This is the UK. Back in Latvia I would just slide my ID card into a USB reader and cryptographically sign the session with a passcode. Same as chip & pin…

> Back in Latvia I would just slide my ID card into a USB reader and cryptographically sign the session with a passcode. I think this is a good authentication model, but it costs money. There is the upfront cost of the physical card, and then the higher cost of lost account recovery. I think that's the turn-off to most banks; they will have to staff a call center that can verify your ID, issue a new card, and then de…

You’re taking a well-known system, criticising it, and burying the fact you’re from the US well inside of that.

We’ve already solved this problem outside of America you know.

Post reply on HN