Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Frequent reauth doesn't make you more secure

tailscale.com

Post reply on HN
Print view View original

21–30 of 539 posts

Re: Frequent reauth doesn't make you more secure

#21

Post by ffsm8 »

paxys wrote: post #8
andrewmcwatters wrote: post #5

Earlier quoted context omitted.

Uh, session cookies being one of the most fundamental pieces of authentication tech, there's nothing wrong with them. This is like saying, "example.com actually uses HTTPS. It's infuriating." Do you mean that you have to reauth across domains? Those still use session cookies. Edit: I'm dating myself here, but as far as I can tell apparently sometime between 2010 and 2011, developers started referring to session cooki…

No, sites use persistent cookies , which remain on your browser after you have closed the tab. Session cookies are wiped out automatically after every session.

I think some developers will interpret the term "session cookie" differently then that, because a "session" is usually just something that's tracked in a backend, and an identifier for this session is often written in a cookie

Hence... Session cookie, even if set without expiration date

Re: Frequent reauth doesn't make you more secure

#22

Post by jeremyjh »

paxys wrote: post #16

Corporate IT still makes you change your password every N months. Tell them to extend the max session length beyond a day and some VP will have an aneurysm.

There is very little incentive to actually do information security correctly - because hardly anyone can tell if you have - consequently there are very few people who try. It is all just theater to cover their asses, and they'll admit it under the right circumstances.

They don't want to change idiotic policies like this because it means they'd have to admit they've been dogmatically enforcing counter-productive policies for decades.

Re: Frequent reauth doesn't make you more secure

#23

Post by Spooky23 »

Only if you make a bunch of assumptions that may not apply. My employer allows BYO and has a default Outlook Web session timeout.

Is it ok that my son stopped at my desk at home and saw customer PII that was left open?

I enforce these kinds of policies at my company even though I find them personally stupid. I do so because I’m the custodian of my customers property and have a duty to minimize risk of employees or contractors acting poorly.

Re: Frequent reauth doesn't make you more secure

#24

Post by antihero »

d4mi3n wrote: post #7

Frequent reauth doesn't meaningfully improve your security posture (unless you have a very, very long expiry), but any auth system worth it's salt should have the capability to revoke a session, either via expiry or by user/device. In practice, I find that the latency between when you want to revoke a session to when that session no longer has access to anything is more important than how often you force reauthentica…

This is why you have refresh tokens - your actual token expires regularly, but the client has a token that allows you to get a new one. Revoking is a case of not allowing them to get a new one.

Re: Frequent reauth doesn't make you more secure

#25

Post by jeremyjh »

valenterry wrote: post #20

This is spot on. And it's a general misunderstanding of security in practice. Availability is often missed/ignored (but it is part of security) and attention is an important currency that needs to be treated carefully - or you and up with the mentioned MFA fatigue attacks or people writing down their passwords.

The most secure thing would be to unplug the servers.

edit: I'm agreeing with parent. Availability is part of security. If it weren't, you could unplug the server and call it a day.

Re: Frequent reauth doesn't make you more secure

#26

Post by dheera »

d4mi3n wrote: post #7

Frequent reauth doesn't meaningfully improve your security posture (unless you have a very, very long expiry), but any auth system worth it's salt should have the capability to revoke a session, either via expiry or by user/device. In practice, I find that the latency between when you want to revoke a session to when that session no longer has access to anything is more important than how often you force reauthentica…

Frequent reauth only makes people figure out hacks to work around it.

Passwords get written down, passwords end up in Google Docs, Arduinos with servos get attached to Yubikeys, SMS gets forwarded to e-mail, TOTP codes get sent over Wechat, the whole works

Re: Frequent reauth doesn't make you more secure

#27

Post by tetha »

d4mi3n wrote: post #7

Frequent reauth doesn't meaningfully improve your security posture (unless you have a very, very long expiry), but any auth system worth it's salt should have the capability to revoke a session, either via expiry or by user/device. In practice, I find that the latency between when you want to revoke a session to when that session no longer has access to anything is more important than how often you force reauthentica…

I was somewhat pondering along these lines.

At work, we have somewhat of a two-staged auth: Once or at most twice a day, you login via the ADFS + MFA to keycloak, and then most systems depend on keycloak as an OIDC provider with 10 - 15 minute token lifetimes. This way you have some login song and dance once a day usually, but on the other hand, we can wipe all access someone has within 15 minutes or less for services needing the VPN. And users don't notice much of this during normal operation.

Re: Frequent reauth doesn't make you more secure

#28

Post by kevin_thibedeau »

antihero wrote: post #24
d4mi3n wrote: post #7

Frequent reauth doesn't meaningfully improve your security posture (unless you have a very, very long expiry), but any auth system worth it's salt should have the capability to revoke a session, either via expiry or by user/device. In practice, I find that the latency between when you want to revoke a session to when that session no longer has access to anything is more important than how often you force reauthentica…

This is why you have refresh tokens - your actual token expires regularly, but the client has a token that allows you to get a new one. Revoking is a case of not allowing them to get a new one.

That's a great way to interfere with local work when the network goes down.

Re: Frequent reauth doesn't make you more secure

#29

Post by d4mi3n »

antihero wrote: post #24
d4mi3n wrote: post #7

Frequent reauth doesn't meaningfully improve your security posture (unless you have a very, very long expiry), but any auth system worth it's salt should have the capability to revoke a session, either via expiry or by user/device. In practice, I find that the latency between when you want to revoke a session to when that session no longer has access to anything is more important than how often you force reauthentica…

This is why you have refresh tokens - your actual token expires regularly, but the client has a token that allows you to get a new one. Revoking is a case of not allowing them to get a new one.

This is an implementation detail in my opinion. There are cases where having the capability to force a refresh is desired. There are also cases where you want to be able to lock out a specific session/user/device. YMMV, do what makes sense for your business/context/threat model.

Re: Frequent reauth doesn't make you more secure

#30

Post by rafaelmn »

kevin_thibedeau wrote: post #28
antihero wrote: post #24

Earlier quoted context omitted.

This is why you have refresh tokens - your actual token expires regularly, but the client has a token that allows you to get a new one. Revoking is a case of not allowing them to get a new one.

That's a great way to interfere with local work when the network goes down.

Access tokens are used for network calls so if the network is down nothing works anyway ?
Post reply on HN