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

291–300 of 434 posts

Re: Short session expiration does not help security

#291

Post by [deleted] »

_jal wrote: post #203
generalizations wrote: post #90

Earlier quoted context omitted.

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…

> The problem with 'defense in depth' No, that's a problem with bad engineering. That a process requires skills most people attempting it don't have isn't a problem with the process, it just means that it is hard and relatively new. One thing I see all the time that demonstrates this incompetence is talking about something being more or less "secure" without reference to a threat model. You simply can't make reasonab…

[deleted]

Re: Short session expiration does not help security

#292

Post by vidarh »

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…

I'm Norwegian, but have lived in the UK since 2000, so I've seen the evolution step by step, and UK banks have pretty much just kept adding new steps every time fraud got too bad instead of rethinking things properly. It's infuriating.

Norway has a near universal electronic signature solution not quite the same as your Latvian one but sounds similar-ish (and there's a EU/EEA requirement to require mutual recognition at some point) and it feels much better (e.g. the Norwegian ones allow access to government websites as well, and can be used to sign contracts etc. - I'm assuming the Latvian one has similar options).

Re: Short session expiration does not help security

#294

Post by fideloper »

Short session lengths are often demanded as a thing to do (or provide as an option users can opt into) to remediate “issues” found from security audits.

It’s an easy enough box to check and so it’s often checked.

That’s why you’ll see them banks and other regulated environments, or on apps that provide soc2 or otherwise have been through security audits (google makes you do an audit of you use certain APIs).

Re: Short session expiration does not help security

#295

Post by gabereiser »

8organicbits wrote: post #65
gabereiser wrote: post #36

Neither does “Your password cannot match your previous 1,000 passwords”. Let’s just keep everyone’s password and previous password around in a database shall we?

That usually works by storing the password hash, not the password itself.

yeah, definitely not advocating keeping plain text passwords, ever. But previous history of hashes is bad too if the database is leaked.

Re: Short session expiration does not help security

#296

Post by ljm »

vidarh wrote: post #292
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 Norwegian, but have lived in the UK since 2000, so I've seen the evolution step by step, and UK banks have pretty much just kept adding new steps every time fraud got too bad instead of rethinking things properly. It's infuriating. Norway has a near universal electronic signature solution not quite the same as your Latvian one but sounds similar-ish (and there's a EU/EEA requirement to require mutual recognition…

Yeah your ID in Latvia has an electronic certificate for governments, banks, etc

Re: Short session expiration does not help security

#297

Post by gabereiser »

vel0city wrote: post #70
gabereiser wrote: post #36

Neither does “Your password cannot match your previous 1,000 passwords”. Let’s just keep everyone’s password and previous password around in a database shall we?

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…

You should never keep plain text passwords. bcrypt it at the very least. I'm referring to keeping a history of those hashes around to compare against other leaked databases one would find on the dark web. Having a history of the last password hashes are n+1 as bad as storing a password hash.

Re: Short session expiration does not help security

#298

Post by dcow »

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…

To be honest I feel like biometric app unlock has largely made the need for the short tokens banking experience obsolete. I don’t want to change my credential ever 15 minutes, I just want my bank app to verify my biometrics on sensitive operations. The only real reason for short lived bearer “tokens” these days is so you can deploy them in scenarios without revocation lists.

Re: Short session expiration does not help security

#299

Post by EGreg »

And yet ITP destroys all cookies after 7 days, even first-party cookies, unless your site never uses any other third-party iframes or hosts servers in multiple data centers.

But they do it to prevent websites tracking their own visitors without their consent for more than 7 days… I think.

So session expire not just to spite you.

But the question is — given that the cache is totally cleared, after 7 days, can iOS safari ever guarantee that a specific URL will NEVER be replaced by a server to something else? With non-expiring caching, we could! But now?

Re: Short session expiration does not help security

#300

Post by forty »

grinich wrote: post #118
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…

There’s a solution for this! It’s called SCIM and it lets you sync user updates from the directory so you can expire sessions when users are deactivated. (I work at WorkOS.com which helps developers with this.)

I'd rather rely on session expiration rather than on the fact the SCIM sync works well. I implemented SAML and SCIM services. With SAML you implement things once, tweak it a bit, and then it works with all the IdP, even those you never heard of. SCIM on the other hand have only 2 client implementation that I'm aware of (at the time I worked with it at least) and they were sufficiently different from each other than you kind of had to do 2 implementations. Not to mention it uses stupid JSON patch thing that are crap to work with unless you use mongodb or similar I guess. And stupid limitations on forcing the sync on AzureAD that I forgot the details of.
Post reply on HN