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

421–430 of 434 posts

Re: Short session expiration does not help security

#421

Post by pxc »

Nemi wrote: post #404
pxc wrote: post #378

Earlier quoted context omitted.

Is there a term for this kind of thinking, or a type of job role in security that focuses on problems like this? Are there any professional 'strategic rearranger of security complexity' or 'security UX champion' jobs out there? This seems like it could be a really valuable and maybe also fun role, if one can find an org that has made room for it.

This isn’t a security mindset, it is a product development mindset. You run into problems creating these situations like we are discussing when roles across the company diverge and no one is responsible for the big picture. The security guy doesn’t care about product management, and the product guy usually doesn’t see the value in security. Good founders get this.

A lot of the same problems come up later in the software lifecycle, though. I wish considerations like this could be a factor in purchase and integration considerations.

Re: Short session expiration does not help security

#422

Post by dwaite »

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…

> 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

Both SAML 2 and OIDC have standard mechanisms to expire sessions.

One problem is that sessions are always a per-site, bespoke technology. Flagging a session as expired in a back-end database isn't going to help if the front-end uses cookies holding JWTs as an optimization.

So some sites prefer front-end expiry (which is also standardized by both). Some sites won't bother to support either.

Add on the inconsistent behavior of cookies across browsers these days, and it becomes very hard to support. It has been prioritized out of most things.

There is also the issue that sign-out doesn't make sense for many things. Logging out of Google in my browser shouldn't kill my Discord desktop session just because I chose the SSO option for authentication.

SLO makes sense in enterprise scenarios (where many big SaaS products tend to still not support it) and in single-party consumer scenarios - where SSO is used as integration glue to make something that "looks" like it is all one site, such as first-party Google logins.

Re: Short session expiration does not help security

#423

Post by dwaite »

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 length of time an access token is a delegated authorization, not an authentication session. For first party mobile apps and the like, they might act similarly, but for other use cases they will not.

The access token may be so my account at an event coordination site has free/busy access to my Google calendar, and that authorization might last for years.

Re: Short session expiration does not help security

#424

Post by dwaite »

unscaled wrote: post #368
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…

The main problem is the way these standards are implemented. OAuth 2.0 (on which OIDC is based) does define a reliable back channel for session revocation, although it is still pull-based instead of push-based. The scheme is simple: 1. Use short-lived access tokens (forcing clients to refresh often) 2. Check for revocation on every token refresh There is even an OAuth 2.0 RFC for a token revocation API[1], and an Ope…

> The main problem is the way these standards are implemented. OAuth 2.0 (on which OIDC is based) does define a reliable back channel for session revocation…

The larger issue is that even if you had a reliable revocation system - most relying parties wouldn't use it.

The typical relying party supports logins from Facebook, Google, Apple and the like because the user chose to use those as authentication systems. However, the relying party is independent. The user would not expect other sites and desktop apps to suddenly stop working because the user hadn't visited Facebook for a certain number of hours.

There were efforts in the past using transparent pixels on the identity domain to do distributed session tracking - e.g. if I'm interacting with _any site_ using the login, that will encourage the session to stay alive. Turns out that was way too much visibility for social login providers to have.

Re: Short session expiration does not help security

#425

Post by Prickle »

nickserv wrote: post #377
jrockway wrote: post #362

Earlier quoted context omitted.

Ah, that's the key. We'd never get a national ID in the US, instead ironically forcing the costly KYC onto each individual bank. (And Twitter now apparently.)

There's already a Federal ID required for banking in the US: your social security number.

Except that when it was first implemented, the government explicitly stated that the Social Security Number was not a valid ID.

https://www.npr.org/2018/03/22/596180023/how-social-security...

Due to this, it is fundamentally missing multiple levels of security. You can actually guess someone's SSN within 2 digits if you know their date of birth, and location of/hospital of birth.

Re: Short session expiration does not help security

#426

Post by matheusmoreira »

photonerd wrote: post #406
matheusmoreira wrote: post #402

Earlier quoted context omitted.

My parents giving me a name is one thing. The state giving me a number and arresting me if I fail to produce that number to police on demand is another.

It’s funny you think there’s a difference

It's funny you think there isn't a difference between the humanity of your parents and some faceless governamental bureaucracy.

Re: Short session expiration does not help security

#427

Post by matheusmoreira »

msm_ wrote: post #414
matheusmoreira wrote: post #373

Earlier quoted context omitted.

Which is dehumanizing. We are not cattle to be identified and marked.

But you need a way to identify people. If there's no good way to identify real people (government issued ID number), those that need them will invent bad ones (SSN, phone number, maiden name, maybe more). And companies like Google have their own identifier for you already, anyway. And you can't travel anywhere without a passport that is another identifier, anyway. I'm impressed how much Americans dislike the idea of…

I'm not american. Not only do I want the government to know nothing at all about me, I also want it to be illegal for others to develop those alternative identification methods. Those who "need" such things should have to figure out a way to avoid needing it.

Re: Short session expiration does not help security

#428

Post by ExoticPearTree »

williamcotton wrote: post #303
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…

I’m so envious of the Baltic’s use of technology at the institutional level. It seems literally infeasible for the United States to have state-issued PKI. It’s a meta-partisan issue: no side trusts the other to manage crypto or computer systems. So for example instead of a public many-to-many digital publishing platform we are stuck with the whims of grown men who want to fist fight each other in the Colosseum and al…

> I’m so envious of the Baltic’s use of technology at the institutional level.

You shouldn't. I don't know if anything changed in the last few years, but having to insert your ID into a card reader is very cumbersome from a user experience perspective. Especially since the world is moving away from having to plug stuff into computers.

Re: Short session expiration does not help security

#429

Post by tremon »

matheusmoreira wrote: post #402
photonerd wrote: post #400

Earlier quoted context omitted.

Ah so you are the man with no name, I assume?

My parents giving me a name is one thing. The state giving me a number and arresting me if I fail to produce that number to police on demand is another.

Which one of those is problematic to you? The state giving you a number or arresting you if you refuse to identify yourself? Because you've given yourself a nice straw man to fight by conflating them.

Re: Short session expiration does not help security

#430

Post by timtom39 »

ljm wrote: post #286
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…

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…

In Latvia what happens if you lose your ID?
Post reply on HN