13 ms·

> 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

> 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 particular security feature may fail or be bypassed in some way. What are the consequences of this? Well, it means that you want multiple layers of security. Your server runs its daemons with minimal privileges so that a remote execution vulnerability needs to be combined with a privilege escalation vulnerability. You don’t think about the “right way” to secure something, but you think about multiple ways to secure something, and don’t stop securing it just because you’ve found one good option. Short sessions are there because there are various ways that sessions could be compromised.

horsawlarway 3y ago
> 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 (ex: you have user access on a local machine, or physical hardware access, or you're an admin who manages that user, etc/etc/etc). So an expired session is, at most, a small speed bump in those cases. So... going back to the point: If expiring sessions is terrible UX (and it is) and it's not stopping attackers (and it's not), why are you doing it? ---- > You don’t think about the “right way” to secure something, but you think about multiple ways to secure something, and don’t stop securing it just because you’ve found one good option. This attitude is cancer. Let me throw another quote at you: "A ship in harbor is safe - but that is not what ships are built for." ---- 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!
- MattPalmer1086 3y ago
  > This attitude is cancer. Let me throw another quote at you Nonsense, defence in depth is a core security principle. You should not rely on a single control to protect you.
  - horsawlarway 3y ago
    > Nonsense, defence in depth is a core security principle. You should not rely on a single control to protect you. And you should not prioritize security over the goal of the product. The conversation is a discussion of relative value and tradeoffs. Does increasing security make the tool as a whole worse? Sometimes - the answer is yes. I have a nice set of front windows, but that means a risk of someone breaking through them. I accept that risk for the windows - the extra light and visibility is well worth it, and the windows are not the only way in. Compare to short sessions.
    - cj 3y ago
      The idea of “adaptive security” is compelling. E.g. my bank makes me type my password and sends 2fa codes when initiating/approving wire transfers… even when I just logged in a minute ago. If I’m doing 2 wire transfers in a row, it doesn’t care, it still has me fully reauthenticate for every wire transfer. But I’m fine with that because moving money is something that I’m willing to accept however many roadblocks are thrown at me. But do I want that happening when I go to post a tweet? Absolutely not. In other words, let’s adopt the concept of refreshing authentication upon particularly sensitive user actions and have lax requirements in other cases. We don’t need to think of sessions as “logged in” or “logged out”. It’s possible to design a system where you’re always logged in forever, but you need to reauthenticate based on certain rules or actions given the context of the app and risk/threat.
      - horsawlarway 3y ago
        Agreed - this is a much better approach. The "session" that can do the normal daily tasks for users should last as long as you can make it. The "session" that can do things like change 2fa/billing/contact-info (decidedly not-normal things) should last for exactly as long as it takes you to complete that form, and should require your pass/2fa again to touch. This is currently Google's approach, and I find it much more sane.
dakial1 3y ago
The author also puts lot’s of faith on the user not doing stupid things: “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, no matter how short the session expiry time is.” Yeah, users might just leave their bank logged in a open and logged computer library. That’s why short sessions exist for those as this will limit the window of opportunity for a bad actor to do something bad. Not perfect of course, but limit the exposure.
- horsawlarway 3y ago
  > Not perfect of course, but limit the exposure. It's a shared computer (and if the session is carrying over, it's not just shared hardware it's a shared account). In this case - you are utterly fucked if you think that machine is secure. Hell, fuck the session, I'll just run a keylogger (or if I'm not admin, install a malicious browser extension) and capture your whole login - I have considerably more access to this machine than I need to compromise you in a large number of ways.
  - water9 3y ago
    And get ATM machines work every day on the principle of asking you to just re-enter your password on potentially harmful transactions. Let’s also pretend like there’s a security camera looking at my desk that is usually not monitored, but you don’t know that
  - philote 3y ago
    Maybe the machine is secured by not allowing anything further to be installed on it. Or maybe it's not. I've heard most crimes are due to opportunity, so it's best to protect your users from accidentally leaving themselves logged in on a shared computer for the next person to find that opportunity.
  - vidarh 3y ago
    > I'll just run a keylogger You could. But what is relevant is whether you have. The point is not to protect against a determined attacker, but to reduce the chance of an opportunistic attack. It really feels like most people have little experience with shared computer resources any more, because pranking people who left their computer unlocked used to be practically a sport, even when the same people would (mostly) never go out of their way to attack a locked down account. Screen locks became a thing long before mobile devices for a reason.
GoblinSlayer 3y ago
Librewolf has an option to delete cookies on exit. Then you are as secure as possible.
- mgbmtl 3y ago
  Except if the cookie is copied elsewhere, then that cookie/session needs to be expired? (but yes, expiring locally reduces the window for copying that cookie)
- eli 3y ago
  Pretty sure every browser does
datavirtue 3y ago
Short sessions are obscurity...not security. If you use a serious website like Fidelity's, they don't let you do anything impactful without an authentication challenge. You could have logged in a few seconds ago...want to tinker with bank accounts? Challenge.
- thinkmassive 3y ago
  Fidelity also logs you out after a short duration of inactivity…
Frost1x 3y ago
>One fact about security which you cannot avoid is that any one particular security feature may fail or be bypassed in some way. What are the consequences of this? Well, it means that you want multiple layers of security. I think the problem here is that no one ever attempts to define what "multiple" is in layers. Most seem to agree that one layer often isn't enough for the reason pointed out. The issue I take is no one knows or provides any sort of guidance of how many layers are enough. People working in security take a degree of liability in their jobs, perhaps careers, for compromises. As such, all the incentives are to add as many layers as possible, everywhere. So we get N-factor Auth, continuously expiring passwords, biometrics, regularly expiring physical access credentials, sessions that are increasingly fleeting and often work requires layers of these sessions so you end up with multiple compounding needs to reauthenticate to the network, to some remote application debugger, to some application running within an application, and so on. I often work in secure environments and it gets tiring, tiring to the point I admittedly start to take shortcuts to make my life easier, shortcuts that ultimately defeat a few layers of security in some way to keep my sanity so I can... do the actual work. So the other extreme of 1 layer of security is N layers of security where nothing is ever usable. There need to be some reasonable protocols in place and people who write them need to be forced to actually go through the use cases with a combination of efficiency/production quotas. Only then do I believe security starts to realize an appropriate balance of layering security and creating value. In the current state of affairs, a lot of places are off the rails where they add so many barriers for normal use they create behaviors in authorized users to open very bad holes whereas if a few layers were peeled back and appropriately managed, the overall security of a given system would likely improve.
- tetha 3y ago
  > I often work in secure environments and it gets tiring, tiring to the point I admittedly start to take shortcuts to make my life easier, shortcuts that ultimately defeat a few layers of security in some way to keep my sanity so I can... do the actual work. Yeah, and without getting as agitated as that other guy in the comment thread, this is where security becomes its own enemy. And how achieving effective, practical security is a lot more subtle than it seems. For example, we've been talking about putting 2FA onto the identity provider allowing access to internal high privilege administrative interfaces, for example via Duo, which requires you to authorize a login via your phone. However, an important question there was: How long would we trust a 2FA authorization? If every single login after a session expiration requires 2FA, people would riot and/or start looking for workarounds. That's not great. But eventually, we ended up trusting a 2FA authorization for like 12 hours. That's one work day, even if it goes longer. Usually this means you have 2 Duo pings in the morning - one for the VPN and one for the internal IDP. That's entirely acceptable imo. And in a similar sense, SSO can increase security while increasing convenience as well. For example, our ADFS allows sessions of about 4 hours, so if you access it once in the morning and once during midday, you stay logged in. And this in turn allows systems like the Keycloak acting as an IDP to work with very short session timeouts. As long as you're working, your keycloak session remains active. Once you're not active for 5-10 minutes, you're logged out from keycloak - but that's just 1-2 redirects on the next click and you're back in. And once this is simple and convenient, people want to use this. And suddenly you got rid of a mess of local accounts in different systems and everything is based on the central directory. And that, in turn, is more valuable than validating MFA multiple times a day in the grander context, at least in my book.
sgustard 3y ago
Also pointless: "your session will expire in X minutes; click Continue to stay logged in" alerts. That just turns a short session into a long session? And provides a handy session.renew() call for the attacker?
jmull 3y ago
> This one line is emblematic of the flaws in the article. I don't think you can reasonably dismiss this article based on that line. (1) It's just an aside, not part of the main argument; (2) It happens to be true. Anyway... "Who knows, it might help" is OK (well, better than nothing), when there's not a significant cost to pay. But when there is, you need to go deeper. There's a tradeoff being made and if you don't think of it that way, you're going to make a poor decision.
lelanthran 3y ago
> “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.” Isn't the reverse also true? Imagine that everything else in a system is done incorrectly, and the system, overall, is completely insecure. In this imaginary world, short sessions don’t help. At any point between "perfectly secured system" and "completely borked security in every single layer", in what way will short sessions help? If you've got a good and secure setup, with maybe one or two holes you don't know about, how does a short session help?
willio58 3y ago
Fully agreed. Just because 1 security measure doesn't prevent all malicious attacks, doesn't mean that it "does not help security". It's just fundamentally false because some malicious attacks rely on long expirations, therefore for those attacks, this method does help security. Not all malicious attempts are refined or perfectly executed and sometimes a user can simply rely on a token that lasts too long. It's a clickbait title and it worked. A title like this would be much more accurate: "Short session expirations provide less security than you might think"
deleted 3y ago
[deleted]
fnordpiglet 3y ago
I tend to agree with respect to machine sessions where tokens are handed around and persisted and the cost of reauthing bothers no one. Sessions should be as short as is reasonable for performance. For human applications you should generally not expire general access but expire leases to critical actions. Generally there are more and less sensitive realms of actions and read that a user can do, with a non linear continuum of risk and user pain. Logging in and browsing your content - fine. Mutating, deleting, viewing sensitive like credentials, creating new credentials, changing credentials, etc - reauth either every time or with some short window like 5 minutes.
foobiekr 3y ago
Short sessions are there because, for all practical purposes, SLO doesn't work and we are using short sessions to simulate high-latency SLO. In a previous life we supported SLO properly, and it had no value at all. It's one of the many sad realities of the modern world that basic functions don't work and no one will fix them.

horsawlarway 3y ago

> 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 (ex: you have user access on a local machine, or physical hardware access, or you're an admin who manages that user, etc/etc/etc). So an expired session is, at most, a small speed bump in those cases. So... going back to the point: If expiring sessions is terrible UX (and it is) and it's not stopping attackers (and it's not), why are you doing it? ---- > You don’t think about the “right way” to secure something, but you think about multiple ways to secure something, and don’t stop securing it just because you’ve found one good option. This attitude is cancer. Let me throw another quote at you: "A ship in harbor is safe - but that is not what ships are built for." ---- 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!

MattPalmer1086 3y ago
> This attitude is cancer. Let me throw another quote at you Nonsense, defence in depth is a core security principle. You should not rely on a single control to protect you.
- horsawlarway 3y ago
  > Nonsense, defence in depth is a core security principle. You should not rely on a single control to protect you. And you should not prioritize security over the goal of the product. The conversation is a discussion of relative value and tradeoffs. Does increasing security make the tool as a whole worse? Sometimes - the answer is yes. I have a nice set of front windows, but that means a risk of someone breaking through them. I accept that risk for the windows - the extra light and visibility is well worth it, and the windows are not the only way in. Compare to short sessions.
  - cj 3y ago
    The idea of “adaptive security” is compelling. E.g. my bank makes me type my password and sends 2fa codes when initiating/approving wire transfers… even when I just logged in a minute ago. If I’m doing 2 wire transfers in a row, it doesn’t care, it still has me fully reauthenticate for every wire transfer. But I’m fine with that because moving money is something that I’m willing to accept however many roadblocks are thrown at me. But do I want that happening when I go to post a tweet? Absolutely not. In other words, let’s adopt the concept of refreshing authentication upon particularly sensitive user actions and have lax requirements in other cases. We don’t need to think of sessions as “logged in” or “logged out”. It’s possible to design a system where you’re always logged in forever, but you need to reauthenticate based on certain rules or actions given the context of the app and risk/threat.
    - horsawlarway 3y ago
      Agreed - this is a much better approach. The "session" that can do the normal daily tasks for users should last as long as you can make it. The "session" that can do things like change 2fa/billing/contact-info (decidedly not-normal things) should last for exactly as long as it takes you to complete that form, and should require your pass/2fa again to touch. This is currently Google's approach, and I find it much more sane.

dakial1 3y ago

The author also puts lot’s of faith on the user not doing stupid things: “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, no matter how short the session expiry time is.” Yeah, users might just leave their bank logged in a open and logged computer library. That’s why short sessions exist for those as this will limit the window of opportunity for a bad actor to do something bad. Not perfect of course, but limit the exposure.

horsawlarway 3y ago
> Not perfect of course, but limit the exposure. It's a shared computer (and if the session is carrying over, it's not just shared hardware it's a shared account). In this case - you are utterly fucked if you think that machine is secure. Hell, fuck the session, I'll just run a keylogger (or if I'm not admin, install a malicious browser extension) and capture your whole login - I have considerably more access to this machine than I need to compromise you in a large number of ways.
- water9 3y ago
  And get ATM machines work every day on the principle of asking you to just re-enter your password on potentially harmful transactions. Let’s also pretend like there’s a security camera looking at my desk that is usually not monitored, but you don’t know that
- philote 3y ago
  Maybe the machine is secured by not allowing anything further to be installed on it. Or maybe it's not. I've heard most crimes are due to opportunity, so it's best to protect your users from accidentally leaving themselves logged in on a shared computer for the next person to find that opportunity.
- vidarh 3y ago
  > I'll just run a keylogger You could. But what is relevant is whether you have. The point is not to protect against a determined attacker, but to reduce the chance of an opportunistic attack. It really feels like most people have little experience with shared computer resources any more, because pranking people who left their computer unlocked used to be practically a sport, even when the same people would (mostly) never go out of their way to attack a locked down account. Screen locks became a thing long before mobile devices for a reason.

GoblinSlayer 3y ago

Librewolf has an option to delete cookies on exit. Then you are as secure as possible.

mgbmtl 3y ago
Except if the cookie is copied elsewhere, then that cookie/session needs to be expired? (but yes, expiring locally reduces the window for copying that cookie)
eli 3y ago
Pretty sure every browser does

datavirtue 3y ago

Short sessions are obscurity...not security. If you use a serious website like Fidelity's, they don't let you do anything impactful without an authentication challenge. You could have logged in a few seconds ago...want to tinker with bank accounts? Challenge.

thinkmassive 3y ago
Fidelity also logs you out after a short duration of inactivity…

Frost1x 3y ago

>One fact about security which you cannot avoid is that any one particular security feature may fail or be bypassed in some way. What are the consequences of this? Well, it means that you want multiple layers of security. I think the problem here is that no one ever attempts to define what "multiple" is in layers. Most seem to agree that one layer often isn't enough for the reason pointed out. The issue I take is no one knows or provides any sort of guidance of how many layers are enough. People working in security take a degree of liability in their jobs, perhaps careers, for compromises. As such, all the incentives are to add as many layers as possible, everywhere. So we get N-factor Auth, continuously expiring passwords, biometrics, regularly expiring physical access credentials, sessions that are increasingly fleeting and often work requires layers of these sessions so you end up with multiple compounding needs to reauthenticate to the network, to some remote application debugger, to some application running within an application, and so on. I often work in secure environments and it gets tiring, tiring to the point I admittedly start to take shortcuts to make my life easier, shortcuts that ultimately defeat a few layers of security in some way to keep my sanity so I can... do the actual work. So the other extreme of 1 layer of security is N layers of security where nothing is ever usable. There need to be some reasonable protocols in place and people who write them need to be forced to actually go through the use cases with a combination of efficiency/production quotas. Only then do I believe security starts to realize an appropriate balance of layering security and creating value. In the current state of affairs, a lot of places are off the rails where they add so many barriers for normal use they create behaviors in authorized users to open very bad holes whereas if a few layers were peeled back and appropriately managed, the overall security of a given system would likely improve.

tetha 3y ago
> I often work in secure environments and it gets tiring, tiring to the point I admittedly start to take shortcuts to make my life easier, shortcuts that ultimately defeat a few layers of security in some way to keep my sanity so I can... do the actual work. Yeah, and without getting as agitated as that other guy in the comment thread, this is where security becomes its own enemy. And how achieving effective, practical security is a lot more subtle than it seems. For example, we've been talking about putting 2FA onto the identity provider allowing access to internal high privilege administrative interfaces, for example via Duo, which requires you to authorize a login via your phone. However, an important question there was: How long would we trust a 2FA authorization? If every single login after a session expiration requires 2FA, people would riot and/or start looking for workarounds. That's not great. But eventually, we ended up trusting a 2FA authorization for like 12 hours. That's one work day, even if it goes longer. Usually this means you have 2 Duo pings in the morning - one for the VPN and one for the internal IDP. That's entirely acceptable imo. And in a similar sense, SSO can increase security while increasing convenience as well. For example, our ADFS allows sessions of about 4 hours, so if you access it once in the morning and once during midday, you stay logged in. And this in turn allows systems like the Keycloak acting as an IDP to work with very short session timeouts. As long as you're working, your keycloak session remains active. Once you're not active for 5-10 minutes, you're logged out from keycloak - but that's just 1-2 redirects on the next click and you're back in. And once this is simple and convenient, people want to use this. And suddenly you got rid of a mess of local accounts in different systems and everything is based on the central directory. And that, in turn, is more valuable than validating MFA multiple times a day in the grander context, at least in my book.

sgustard 3y ago

Also pointless: "your session will expire in X minutes; click Continue to stay logged in" alerts. That just turns a short session into a long session? And provides a handy session.renew() call for the attacker?

jmull 3y ago

> This one line is emblematic of the flaws in the article. I don't think you can reasonably dismiss this article based on that line. (1) It's just an aside, not part of the main argument; (2) It happens to be true. Anyway... "Who knows, it might help" is OK (well, better than nothing), when there's not a significant cost to pay. But when there is, you need to go deeper. There's a tradeoff being made and if you don't think of it that way, you're going to make a poor decision.

lelanthran 3y ago

> “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.” Isn't the reverse also true? Imagine that everything else in a system is done incorrectly, and the system, overall, is completely insecure. In this imaginary world, short sessions don’t help. At any point between "perfectly secured system" and "completely borked security in every single layer", in what way will short sessions help? If you've got a good and secure setup, with maybe one or two holes you don't know about, how does a short session help?

willio58 3y ago

Fully agreed. Just because 1 security measure doesn't prevent all malicious attacks, doesn't mean that it "does not help security". It's just fundamentally false because some malicious attacks rely on long expirations, therefore for those attacks, this method does help security. Not all malicious attempts are refined or perfectly executed and sometimes a user can simply rely on a token that lasts too long. It's a clickbait title and it worked. A title like this would be much more accurate: "Short session expirations provide less security than you might think"

deleted 3y ago

[deleted]

fnordpiglet 3y ago

I tend to agree with respect to machine sessions where tokens are handed around and persisted and the cost of reauthing bothers no one. Sessions should be as short as is reasonable for performance. For human applications you should generally not expire general access but expire leases to critical actions. Generally there are more and less sensitive realms of actions and read that a user can do, with a non linear continuum of risk and user pain. Logging in and browsing your content - fine. Mutating, deleting, viewing sensitive like credentials, creating new credentials, changing credentials, etc - reauth either every time or with some short window like 5 minutes.

foobiekr 3y ago

Short sessions are there because, for all practical purposes, SLO doesn't work and we are using short sessions to simulate high-latency SLO. In a previous life we supported SLO properly, and it had no value at all. It's one of the many sad realities of the modern world that basic functions don't work and no one will fix them.