Frequent reauth doesn't make you more secure
tailscale.com
Frequent reauth doesn't make you more secure
1–10 of 539 posts
Re: Frequent reauth doesn't make you more secure
#2But it is easier to implement and maintain so it will continue to be the default.
Re: Frequent reauth doesn't make you more secure
#3[deleted]
Re: Frequent reauth doesn't make you more secure
#4OMG I wish that someone would tell this to Apple.
Apple's developer services, such as App Store Connect, actually use session cookies. It's infuriating.
Re: Frequent reauth doesn't make you more secure
#5OMG I wish that someone would tell this to Apple. Apple's developer services, such as App Store Connect, actually use session cookies. It's infuriating.
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 cookies as cookies with the lifetime of a browser session and not to cookies which contain session data.
If anyone can correct me on that timeline, I'd appreciate it. Sorry for the confusion in my comment.
Re: Frequent reauth doesn't make you more secure
#6This reads like paraphrasing of SPIFFE.
I’m down for it but I wonder of compromised devices that can figure it out how to keep the auth alive (or replicating user behavior). In those cases expiration still sounds like a good idea.
Re: Frequent reauth doesn't make you more secure
#7Frequent 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 reauthentication. This gets particularly thorny depending on your auth scheme and how many moving parts you have in your architecture.
Re: Frequent reauth doesn't make you more secure
#8OMG I wish that someone would tell this to Apple. Apple's developer services, such as App Store Connect, actually use session cookies. It's infuriating.
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.
Re: Frequent reauth doesn't make you more secure
#9> What are we really checking?
That the security policy for the user and the resulting access key hasn't changed their level of access?
Identity, while the most common use case, is only half the system when federating logins.
Re: Frequent reauth doesn't make you more secure
#10Frequent 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…
You don't need reauthenticate for that, you just need to renew existing tokens. Separate the timeouts for authentication and authorization.