11 ms·

> 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, tho

> 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.
      - konschubert 3y ago
        GitHub does this too.
    - ahtihn 3y ago
      > But I’m fine with that because moving money is something that I’m willing to accept however many roadblocks are thrown at me. Really? I'd change banks over that. If I log into my e-banking website, the main activity I'm going to do is pay bills. I would absolutely not tolerate having to jump through hoops to do it.
      - cj 3y ago
- TeMPOraL 3y ago
  Yes, however, in the limit it's also the case that you can have either secure or useful system, but not both. And then, since the top comment was encouraging a wider view, there's even wider view: business needs. Truth is, short sessions make me viscerally hate the product, creates a desire to avoid using it, and becomes a factor in decision to switch to a competing offering when such possibility arises. Or to not switch - one big reason I'm still using my current bank account instead of another one I had to have to get better mortgage rate, is because the bank operating that other account has short session times and associated pseudo-security annoyances.
- marcus0x62 3y ago
  But, you need to make sure the extra controls are actually providing depth. I think in some (very narrow) cases, short session times and aggressive reauth do add depth and can be an effective part of a security program. But, all too often, defense in depth is used to mean: * Vendors In Depth, whereby every security tool under the sun has to be deployed (or at least purchased) to achieve “security”. Or, worse, the Noah’s Ark model where you buy two of everything. * Uncoordinated and/or seemingly random layering of controls that either don’t add to the overall confidentiality, integrity, or availability of the system being protected. Or, worse, are positively counterproductive and actively reduce the real-world security of the system.
  - pxc 3y ago
    > Vendors In Depth Vendors will always love the phrase 'defense-in-depth' more than they care about assessing whether additional layers of tooling and controls actually provide more defense, because a vague appeal to defense-in-depth is a great way to justify purchasing more security software. It would be naive to think this doesn't affect the volume of research produced promoting and emphasizing the importance of defense-in-depth either, or how frequently papers on basically any kind of attack end with something that means 'this is why a defense-in-depth approach is needed in XYZ area' even when defense-in-depth is at best incidental to the substance of the paper. You can trivially tack that on to the end of pretty much any paper about any exploit, which raises the question of how meaningful an observation it really is.
- markhahn 3y ago
  Really, the issue here is that security is never treated quantitatively. At least in my experience - are there examples of quantitative security? In some sense, the problem is that the goal is zero controls breaking, but of course, that also provides no information on security. Intuitively, it would seem that parameterizing security (in a diagnostically useful way) would also require a number of quite different measures. For instance, it matters who (how sophisticated and motivated) your attackers are. And some of the parameterization would be based on use - every time you force someone to type a fixed password, that password is more exposed. Combining all these quantities would just be Bayes-based. I think an exercise like this could be instructive. For instance, short sessions mean more authentications and both usability and failure modes. But they also mean that an attacker would need to wait until the next session, or have a smaller chance of hitting a session. Again, these are quantifiable, at least in rough terms. And this kind of analysis does expose some additional questions: eg that short sessions make no sense without guaranteeing the security of the client system (ideally by reinstallation from known-good reference). At least in my experience, "security people"
  - MattPalmer1086 3y ago
    The closest security generally gets to "quantitative" techniques is in applying risk management to threat models. But the way risk is managed in the industry (multiplying likelihood and impact) is completely incoherent and voodoo. See the book "How to Measure Anything in Cybersecurity Risk" [1] for a good explanation of why it doesn't work and better ways to do it. Which is a long way of saying, no, security doesn't use quantitative techniques mostly, but it would be possible if people understood how to measure and manage risk properly. [1] https://onlinelibrary.wiley.com/doi/book/10.1002/9781119892335 https://onlinelibrary.wiley.com/doi/book/10.1002/97811198923...
deleted 3y ago
[deleted]
izacus 3y ago
> 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? Everytime I get into this kind of discussion, the answer seems to be "because it makes me feel better". Which is why it's so impossible to actually change someones mind about it and thus we have security "experts" (or worse, non-technical managers) making life miserable for thousands of users.
- marcosdumay 3y ago
  As the GP said, the attitude is cancer, and spreading is what it does. It really doesn't help that "security expert" is a job title. That means this person is expected to deal with security, not business objectives, and will be blamed for security incidents, not business goals satisfied. If the OP's attitude is cancer, this is what causes it, and it's completely toxic.
  - greedo 3y ago
    Exactly. Anyone working in a moderately large company (500+ employees) or in a regulated industry is familiar with this issue. Just as no politician wants to be seen as soft on crime, no CISO want's to be blamed for a security breach. So more and more security gets piled on to every process and application. MFA everywhere, even though you're required to use MFA for the VPN. SSO everywhere, because why not. Session expiration after an hour. VPN limited to 8 hour sessions (great for people who work long periods or who have long running processes and don't want to use tmux/screen etc. My team (20+ SREs/admins) spends roughly 40% of our time complying with either security requests, external audits, internal audits, internal queries from Risk/Security about servers etc. Figure the cost to our business of this (just from our team alone) is roughly $1M per annum. Add in the cost of all the "security" software, add another $2M per annum. Staffing of Risk/Security team is probably another $2M per annum. For all the other workers in IT (250 or so) probably another $3M. For non-IT workers, the added friction is easily 10% of their cost, so $15M. Add it up and you're around $25M. And it's not even the out of pocket costs, but the opportunity cost. Thank god I work in a business that has regulative moats that prevent real competition. Cancer is a perfect term for this IT culture.
marcus0x62 3y ago
> 1: A short compromised session is still a compromised session. The duration usually does not prevent the attacker from achieving their goal. Need a citation on that “usually” part. A short session duration most definitely: * Makes it less likely that when an attacker obtains a session token that is is unexpired. * Gives the attacker less time to use a valid session token to move laterally into (potentially) unfamiliar infrastructure. The trade-offs, of course, are: * Poorer UX, and potentially driving users to attempt to bypass approved tools and/or security controls * More interactions with the authentication system, which, depending on the auth system and the attackers motivation/capabilities might actually let them harvest more credentials. But, in any case, I’m not aware of any research that short session tokens don’t thwart attackers use of those tokens, and the idea is, to put it mildy, counterintuitive.
- water9 3y ago
  Once the attacker knows they can steal the session ID, and how long it will be valid for. It’s just a matter of running a script to do that all that as fast as possible.
  - klodolph 3y ago
    That’s one possible scenario. The correct way to evaluate security is to consider many different scenarios, and consider how your mitigations affect the likelihoods of all of them, weighted by their impact.
    - horsawlarway 3y ago
      > The correct way to evaluate security is to consider many different scenarios, and consider how your mitigations affect the likelihoods of all of them, weighted by their impact. NO! that's merely the FIRST step in evaluating security. The next steps are: What sort of threat am I attempting to prevent? How do my mitigations impact usefulness of the product on the whole? And most critically: Are my users better served by adding this security measure? That is much more likely to be determined based on what the product/tool is trying to achieve. Which brings us right back to: Security is a tradeoff. There are situations where I think short sessions make sense (ex: changing billing/contact info). There are also situations where short sessions are huge negatives (ex: how well is slack going to work if you get logged out every 15 minutes?) My proposal is simple: Actually do the damn evaluation, instead of just blindly siding with "moar security = moar better!"
cogman10 3y ago
> A short compromised session is still a compromised session. The duration usually does not prevent the attacker from achieving their goal. I'm a bank robber, I want to steal your money without you knowing so I'm not caught. What would be a better way to do that? Withdraw $1000 immediately or to spread out that withdrawal over several months. A short token forces the $1000 withdraw immediately. And one common way these tokens are compromised is a scammer getting Grandma to open the developer console so they can "fix" things. > 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. Or you are employing the common scam above, screen sharing under the guise of helping. Granted, some of the calculus needs to be "what type of app is this? What does compromise mean?". > The most secure application runs completely isolated, with no input or output, and is totally, utterly useless. But no worries - it's secure! I didn't take this as what the op was saying. Security works in layers and good security imagines that other layers don't exist or might have been compromised. In your ship analogy, that's adding a second hull, putting airtight sections between hull locations, and having lifeboats. You wouldn't eject the lifeboats because "we have two hulls, what could go wrong!" The actual cost of doing this is generally developer time. There are certainly practicality limits, but in general a layered approach to security is how you both increase security and decrease compromise impact.
- horsawlarway 3y ago
  This is just wrong on so many levels. > A short token forces the $1000 withdraw immediately. No, a short token forces the attacker to continue making requests, but otherwise places very few limits on what they can do with it (since these tokens are almost always something like "15 minutes since the last use") > In your ship analogy, that's adding a second hull, putting airtight sections between hull locations, and having lifeboats. This is PERFECT! Because it hightlights exactly the trade off I'm trying to point out. Fucking no one uses double hulls except for oil tankers, and they only do it for a very specific reason: They want to stop oil from leaking out. They pay a HUGE cost for it, but it happens to be worth it for this very specific trade. Here's the tradeoff: --- Double-hulled tankers have a more complex design and structure than their single-hulled counterparts, which means that they require more maintenance and care in operating, which if not subject to responsible monitoring and policing, may cause problems.[2] Double hulls often result in the weight of the hull increasing by at least 20%,[3] and because the steel weight of doubled-hulled tanks should not be greater than that of single-hulled ships, the individual hull walls are typically thinner and theoretically less resistant to wear. Double hulls by no means eliminate the possibility of the hulls breaking apart. Due to the air space between the hulls, there is also a potential problem with volatile gases seeping out through worn areas of the internal hull, increasing the risk of an explosion.[8] --- > The actual cost of doing this is generally developer time. No - the actual costs are usually actual costs, paid by all members of the system. Developer time is just the most obvious up front cost. There is a cost every time a user has to re-authenticate. There is a cost in resources to handle the extra authentications. There is a cost in complexity to maintain and extend the system doing authentication.
jameshart 3y ago
> This attitude is cancer > yes really - fucking always You're really angry with that straw man you've stood up. The OP isn't saying systems have to be locked down to the extent that they're useless. Who would ever argue for such a thing? Note that "You don't stop securing it just because you've found one good option" is NOT the same thing as saying "You don't stop securing it until you've closed every possible security gap and compromised usability". Be charitable in your interpretation. Your OP is making a simple argument that defense in depth is a part of a security posture, precisely because they agree with your core premise, that security is always a tradeoff. Because we won't choose to implement every security measure, and because the security measures we do implement will be flawed, or compromised by the need for the application to actually be usable. Step outside, breathe some fresh air, maybe lay off the coffee first thing. And consider not throwing 'cancer' bombs at passers-by.
- generalizations 3y ago
  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 down systems to the point of uselessness, without actually, technically, preventing work from being done.
  - horsawlarway 3y ago
    Ding ding ding! If you want to defend in depth - more power to you. If the way you're "defending in depth" is mostly not adding security, and is actively making the product less useful... I'm going to call it shite. If you blindly say "defend in depth" without actually... you know... evaluating what that defense does to the product as a whole, you're doing your job poorly.
    - jameshart 3y ago
      The rules of engagement on this site call not for radical candor but for taking the most charitable interpretation of someone's words. Maybe the OP wasn't blindly saying 'defend in depth'? Maybe they were advocating for evaluating what that defense does to the product as a whole? If they were, is their attitude worth describing as cancerous?
User23 3y ago
While security and usability are in some sense opposite poles of a continuum, it’s not strictly a matter of tradeoffs. It’s easy to imagine a decision that considerably decreases the usability of a system without appreciably increasing its security or even decreasing it.
Nemi 3y ago
I couldn’t agree more. Security is almost always user hostile (speaking from a UX perspective). I am NOT advocating that we remove security for obvious reasons (a hacked app is also user hostile). HOWEVER - if we can just acknowledge that security is antithetical to an easy to use, user friendly app then we can make appropriate decisions moving forward. One of my favorite sayings is “if you are not careful, you are going to secure yourself right out of business”. Ease of use is a real thing, and if you don’t figure out a way to make a secure app that is also very easy to use, someone else will and your pleas of “but it is not secure” are going to fall on deaf ears. Honestly, baseline security is part of “essential complexity” https://ferd.ca/complexity-has-to-live-somewhere.html https://ferd.ca/complexity-has-to-live-somewhere.html. Essential complexity can’t be removed, but it CAN be moved around. Right now we are talking about the essential complexity of managing security through managing a user’s session length. The advocated solution is to make sessions short so that they expire quickly. This seems to remove all “accidental complexity” so that we are only dealing with the essential complexity. But this is misleading. There is still complexity in juggling those short sessions. As a designer you think this solution is simple, but what you have done is moved that essential complexity over to your users. THEY must now manage the impact of short sessions. The complexity does not go away, you just moved it to your users, hence it is user hostile. The trick then, if making the best product is important to you, is to figure out a way of letting users have long sessions but managing it on your side. This seems to argue that you are making your system more complex by adding accidental complexity (which is generally a bad thing). But really what you are doing is moving some essential complexity away from your users onto you. You lower their burden. This is how you make competitive applications.
- pxc 3y ago
  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.
  - Nemi 3y ago
rrrpfb11 3y ago
> Security is ALWAYS (fucking always, yes really - fucking always) a tradeoff. It’s helpful to me that ACLs prevent me seeing other users’ files. I’m not trading anything off that I’m aware of.
- horsawlarway 3y ago
  > I’m not trading anything off that I’m aware of. Really? Really???? You're not, say... having to manage ACLs, and having to run a system that can enforce ACLs? Because both of those are tradeoffs. They might be "completely sane and reasonable" tradeoffs! But they are still tradeoffs. Also - in a more blunt way: Simply not being able to see other peoples files was considered a pretty big negative in some computing crowds when it was first enforced. That's a huge tradeoff: You're sacrificing visibility for privacy. I think that turned out to be the correct tradeoff in most places - but to be clear - you absolutely are losing a feature to gain a feature.
  - pxc 3y ago
    > Really? Really???? You're not, say... having to manage ACLs, and having to run a system that can enforce ACLs? In this case, it's a more user-friendly tradeoff, because those burdens can be borne by the infosec staff and other IT staff rather than end users. I'm happy when I can arrange things that way for my own users for sure.
paulddraper 3y ago
> A short compromised session is still a compromised session. The duration usually does not prevent the attacker from achieving their goal. Why "usually does not"? The stolen hard drive, leaked data, etc. can happen at any point in the future....one minute to one year from now. For most of those times, a short session will prevent the attacker from exploiting it. > The vast majority of ways to compromise a session already give you access far beyond that session itself For the local system, yes. But not the for the remote system.
- ilyt 3y ago
  Stolen hard drive is rarely what you defend from, and arguably might completely not matter if say their short lived session is dead but long-lived password manager one is up. Exploits owning software on machine are far more common than machine itself being stolen. I'd also argue that tying re-login to the sensitive actions is far better way to fight it. Basically have long session for nondestructive actions but short for any potentially harmful ones like changing payment options.
  - paulddraper 3y ago
    Stolen hard drive = Stolen laptop/phone/tablet
    - Too 3y ago
      Or decommissioned drives. I’ve seen businesses put used laptops straight up on second hand market, without barely doing basic formatting of the drives, unencrypted. Even less so on private market. Heard from security friends also that there are examples of attacks that succeeded thanks to drives found in trash outside enterprise.
- horsawlarway 3y ago
  > For the local system, yes. But not the for the remote system. This is fair, although you've picked a specific case where the local system would not likely access the remote system again after compromise (because theft removes access for the normal user) and an expired session might be helpful as security. But the other thing about theft is that it also immediately alerts the user, and having a simple "Sign me out everywhere" button is a more robust solution that causes much less user pain and mostly accomplishes the same result. As for > one minute to one year from now. I'm not arguing for indefinite sessions. I'm arguing against short sessions. Rotate it after 30 days if you want (or 5 days, or 1 day - just don't do it every 15 minutes). It'll catch 99% of the cases you're thinking about solving, and it's literally 3000 times less annoying for your users while being nearly as secure.
cortesoft 3y ago
> 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. The worst hack at a company I worked for was caused because an old server that was supposed to be decommissioned was left plugged in and connected to the network… a good time later, a hacker exploited a vulnerability in an unpatched package on the machine and got in (since the server was supposed to be decommissioned it was not patched when the rest of the machines were patched). The hacker used old credentials on the machine to gain access to other machines in our network. If we had been rotating credentials more often, this would not have happened. We had systems in place to patch and maintain our machines, but once the machine got lost in our inventory management system, it was forgotten about. It wasn’t monitored anymore, and other protections lapsed. This category of exploit is prevented by credential rotation, because this type of exploit is only possible if a system is neglected.
- edejong 3y ago
  It could also have been prevented by… not using user credentials on a server to access services? By doing regular checks on your inventory? By using IDS on your complete network? But not trusting your network? (Zero trust security). By regularly simulating attack scenarios and then check your readiness? By implementing ISO27002?
- horsawlarway 3y ago
  > This category of exploit is prevented by credential rotation This category of exploit is prevented in a huge number of ways - not a single one of them is "make my user's cookie/token sessions 15 minutes long"
tlarkworthy 3y ago
When I think of short session expiry I think that access_tokens have a limited timespan so if they get accidentally logged the remote end or the person is fired their access lapses. This is a good idea. If we are talking about bounding the lifetime of a refresh token, I agree with the articles, but that is not what I think of when I think about credential expiry. Credentials that you send to third parties should be short lived. I think without that underlying distinction the article is dangerously confusing. Time-bound credentials have many useful features.
theamk 3y ago
The shorter tokes are useless by themselves; but if combined with proactive security, they can make a real difference. Some concrete examples, based on the places I worked in, which provide support for at least not having infinite expiration: - Attacker steals Google token from regular employee.. What can they do? No, they can't "make themselves admin, or wire all your bitcoin to their account" because such things are not available for regular employees. Nor can they use email to take over account because all stuff that matters uses corporate SSO without automated password resets. So all they have access to corporate google drive, which has few terabytes of not so-valuable-stuff + important documents somewhere. With long-living token, the attacker has plenty of time to browse around and download valuable stuff, perhaps even do it slowly so it can fly under radar. But with the shorter token, this does not work: downloading everything will take too much time / trip the alarms, and manual browsing is not fast enough. (I can imagine some sort of sophisticated AI system which auto-downloads interesting docs, but I am sure most attackers have nothing like this) - Attacker steals AWS credentials -- again, they either have to be fast and get detected (there are alarms on unusual high download rate) or go slow and worry about token expiration. Even if they manage to steal important data, at least the expiration will force them to use faster methods more likely to trip the alarm. Even with the full machine compromise, the short-lived tokens are useful. A npm package which steals all tokens once, at the install time, will likely go undetected. A npm package which installs a persistent backdoor will be much easier to detect.. So having a long-lived token makes attackers' lives much easier.
jameshart 3y ago
> 1: A short compromised session is still a compromised session. But an expired compromised session is not a compromised session. If a session cookie/ID is compromised after it has expired it is no use to anyone. But if a session cookie/ID has no expiry built in, then it remains an open compromise risk forever. Situations where we can expect the session identifier and the context in which it is stored to reasonably be under the control of the user for a short time - while they are actively using a site, say - but where it might not remain under their control after they've finished using it, are a real part of real threat models. If I have some cross-site-request-forgery phishing scam that works on users who are logged in to a bank website, that requires them to have an active session at the time they open their email, or visit my site, or whatever... if their banking sessions time out after 15 minutes of inactivity, they are less vulnerable to that threat than if their browsers keep them logged in all the time.
littlestymaar 3y ago
> 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! Yeah, as the Rust saying goes “The safest code is code that doesn't compile”
dang 3y ago
Can you please not post in the flamewar style to HN? I realize it's the tradition in some online circles, but it's not what this site is for, and destroys what it is for. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

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.
    - konschubert 3y ago
      GitHub does this too.
  - ahtihn 3y ago
    > But I’m fine with that because moving money is something that I’m willing to accept however many roadblocks are thrown at me. Really? I'd change banks over that. If I log into my e-banking website, the main activity I'm going to do is pay bills. I would absolutely not tolerate having to jump through hoops to do it.
    - cj 3y ago
TeMPOraL 3y ago
Yes, however, in the limit it's also the case that you can have either secure or useful system, but not both. And then, since the top comment was encouraging a wider view, there's even wider view: business needs. Truth is, short sessions make me viscerally hate the product, creates a desire to avoid using it, and becomes a factor in decision to switch to a competing offering when such possibility arises. Or to not switch - one big reason I'm still using my current bank account instead of another one I had to have to get better mortgage rate, is because the bank operating that other account has short session times and associated pseudo-security annoyances.
marcus0x62 3y ago
But, you need to make sure the extra controls are actually providing depth. I think in some (very narrow) cases, short session times and aggressive reauth do add depth and can be an effective part of a security program. But, all too often, defense in depth is used to mean: * Vendors In Depth, whereby every security tool under the sun has to be deployed (or at least purchased) to achieve “security”. Or, worse, the Noah’s Ark model where you buy two of everything. * Uncoordinated and/or seemingly random layering of controls that either don’t add to the overall confidentiality, integrity, or availability of the system being protected. Or, worse, are positively counterproductive and actively reduce the real-world security of the system.
- pxc 3y ago
  > Vendors In Depth Vendors will always love the phrase 'defense-in-depth' more than they care about assessing whether additional layers of tooling and controls actually provide more defense, because a vague appeal to defense-in-depth is a great way to justify purchasing more security software. It would be naive to think this doesn't affect the volume of research produced promoting and emphasizing the importance of defense-in-depth either, or how frequently papers on basically any kind of attack end with something that means 'this is why a defense-in-depth approach is needed in XYZ area' even when defense-in-depth is at best incidental to the substance of the paper. You can trivially tack that on to the end of pretty much any paper about any exploit, which raises the question of how meaningful an observation it really is.
markhahn 3y ago
Really, the issue here is that security is never treated quantitatively. At least in my experience - are there examples of quantitative security? In some sense, the problem is that the goal is zero controls breaking, but of course, that also provides no information on security. Intuitively, it would seem that parameterizing security (in a diagnostically useful way) would also require a number of quite different measures. For instance, it matters who (how sophisticated and motivated) your attackers are. And some of the parameterization would be based on use - every time you force someone to type a fixed password, that password is more exposed. Combining all these quantities would just be Bayes-based. I think an exercise like this could be instructive. For instance, short sessions mean more authentications and both usability and failure modes. But they also mean that an attacker would need to wait until the next session, or have a smaller chance of hitting a session. Again, these are quantifiable, at least in rough terms. And this kind of analysis does expose some additional questions: eg that short sessions make no sense without guaranteeing the security of the client system (ideally by reinstallation from known-good reference). At least in my experience, "security people"
- MattPalmer1086 3y ago
  The closest security generally gets to "quantitative" techniques is in applying risk management to threat models. But the way risk is managed in the industry (multiplying likelihood and impact) is completely incoherent and voodoo. See the book "How to Measure Anything in Cybersecurity Risk" [1] for a good explanation of why it doesn't work and better ways to do it. Which is a long way of saying, no, security doesn't use quantitative techniques mostly, but it would be possible if people understood how to measure and manage risk properly. [1] https://onlinelibrary.wiley.com/doi/book/10.1002/9781119892335 https://onlinelibrary.wiley.com/doi/book/10.1002/97811198923...

deleted 3y ago

[deleted]

izacus 3y ago

> 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? Everytime I get into this kind of discussion, the answer seems to be "because it makes me feel better". Which is why it's so impossible to actually change someones mind about it and thus we have security "experts" (or worse, non-technical managers) making life miserable for thousands of users.

marcosdumay 3y ago
As the GP said, the attitude is cancer, and spreading is what it does. It really doesn't help that "security expert" is a job title. That means this person is expected to deal with security, not business objectives, and will be blamed for security incidents, not business goals satisfied. If the OP's attitude is cancer, this is what causes it, and it's completely toxic.
- greedo 3y ago
  Exactly. Anyone working in a moderately large company (500+ employees) or in a regulated industry is familiar with this issue. Just as no politician wants to be seen as soft on crime, no CISO want's to be blamed for a security breach. So more and more security gets piled on to every process and application. MFA everywhere, even though you're required to use MFA for the VPN. SSO everywhere, because why not. Session expiration after an hour. VPN limited to 8 hour sessions (great for people who work long periods or who have long running processes and don't want to use tmux/screen etc. My team (20+ SREs/admins) spends roughly 40% of our time complying with either security requests, external audits, internal audits, internal queries from Risk/Security about servers etc. Figure the cost to our business of this (just from our team alone) is roughly $1M per annum. Add in the cost of all the "security" software, add another $2M per annum. Staffing of Risk/Security team is probably another $2M per annum. For all the other workers in IT (250 or so) probably another $3M. For non-IT workers, the added friction is easily 10% of their cost, so $15M. Add it up and you're around $25M. And it's not even the out of pocket costs, but the opportunity cost. Thank god I work in a business that has regulative moats that prevent real competition. Cancer is a perfect term for this IT culture.

marcus0x62 3y ago

> 1: A short compromised session is still a compromised session. The duration usually does not prevent the attacker from achieving their goal. Need a citation on that “usually” part. A short session duration most definitely: * Makes it less likely that when an attacker obtains a session token that is is unexpired. * Gives the attacker less time to use a valid session token to move laterally into (potentially) unfamiliar infrastructure. The trade-offs, of course, are: * Poorer UX, and potentially driving users to attempt to bypass approved tools and/or security controls * More interactions with the authentication system, which, depending on the auth system and the attackers motivation/capabilities might actually let them harvest more credentials. But, in any case, I’m not aware of any research that short session tokens don’t thwart attackers use of those tokens, and the idea is, to put it mildy, counterintuitive.

water9 3y ago
Once the attacker knows they can steal the session ID, and how long it will be valid for. It’s just a matter of running a script to do that all that as fast as possible.
- klodolph 3y ago
  That’s one possible scenario. The correct way to evaluate security is to consider many different scenarios, and consider how your mitigations affect the likelihoods of all of them, weighted by their impact.
  - horsawlarway 3y ago
    > The correct way to evaluate security is to consider many different scenarios, and consider how your mitigations affect the likelihoods of all of them, weighted by their impact. NO! that's merely the FIRST step in evaluating security. The next steps are: What sort of threat am I attempting to prevent? How do my mitigations impact usefulness of the product on the whole? And most critically: Are my users better served by adding this security measure? That is much more likely to be determined based on what the product/tool is trying to achieve. Which brings us right back to: Security is a tradeoff. There are situations where I think short sessions make sense (ex: changing billing/contact info). There are also situations where short sessions are huge negatives (ex: how well is slack going to work if you get logged out every 15 minutes?) My proposal is simple: Actually do the damn evaluation, instead of just blindly siding with "moar security = moar better!"

cogman10 3y ago

> A short compromised session is still a compromised session. The duration usually does not prevent the attacker from achieving their goal. I'm a bank robber, I want to steal your money without you knowing so I'm not caught. What would be a better way to do that? Withdraw $1000 immediately or to spread out that withdrawal over several months. A short token forces the $1000 withdraw immediately. And one common way these tokens are compromised is a scammer getting Grandma to open the developer console so they can "fix" things. > 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. Or you are employing the common scam above, screen sharing under the guise of helping. Granted, some of the calculus needs to be "what type of app is this? What does compromise mean?". > The most secure application runs completely isolated, with no input or output, and is totally, utterly useless. But no worries - it's secure! I didn't take this as what the op was saying. Security works in layers and good security imagines that other layers don't exist or might have been compromised. In your ship analogy, that's adding a second hull, putting airtight sections between hull locations, and having lifeboats. You wouldn't eject the lifeboats because "we have two hulls, what could go wrong!" The actual cost of doing this is generally developer time. There are certainly practicality limits, but in general a layered approach to security is how you both increase security and decrease compromise impact.

horsawlarway 3y ago
This is just wrong on so many levels. > A short token forces the $1000 withdraw immediately. No, a short token forces the attacker to continue making requests, but otherwise places very few limits on what they can do with it (since these tokens are almost always something like "15 minutes since the last use") > In your ship analogy, that's adding a second hull, putting airtight sections between hull locations, and having lifeboats. This is PERFECT! Because it hightlights exactly the trade off I'm trying to point out. Fucking no one uses double hulls except for oil tankers, and they only do it for a very specific reason: They want to stop oil from leaking out. They pay a HUGE cost for it, but it happens to be worth it for this very specific trade. Here's the tradeoff: --- Double-hulled tankers have a more complex design and structure than their single-hulled counterparts, which means that they require more maintenance and care in operating, which if not subject to responsible monitoring and policing, may cause problems.[2] Double hulls often result in the weight of the hull increasing by at least 20%,[3] and because the steel weight of doubled-hulled tanks should not be greater than that of single-hulled ships, the individual hull walls are typically thinner and theoretically less resistant to wear. Double hulls by no means eliminate the possibility of the hulls breaking apart. Due to the air space between the hulls, there is also a potential problem with volatile gases seeping out through worn areas of the internal hull, increasing the risk of an explosion.[8] --- > The actual cost of doing this is generally developer time. No - the actual costs are usually actual costs, paid by all members of the system. Developer time is just the most obvious up front cost. There is a cost every time a user has to re-authenticate. There is a cost in resources to handle the extra authentications. There is a cost in complexity to maintain and extend the system doing authentication.

jameshart 3y ago

> This attitude is cancer > yes really - fucking always You're really angry with that straw man you've stood up. The OP isn't saying systems have to be locked down to the extent that they're useless. Who would ever argue for such a thing? Note that "You don't stop securing it just because you've found one good option" is NOT the same thing as saying "You don't stop securing it until you've closed every possible security gap and compromised usability". Be charitable in your interpretation. Your OP is making a simple argument that defense in depth is a part of a security posture, precisely because they agree with your core premise, that security is always a tradeoff. Because we won't choose to implement every security measure, and because the security measures we do implement will be flawed, or compromised by the need for the application to actually be usable. Step outside, breathe some fresh air, maybe lay off the coffee first thing. And consider not throwing 'cancer' bombs at passers-by.

generalizations 3y ago
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 down systems to the point of uselessness, without actually, technically, preventing work from being done.
- horsawlarway 3y ago
  Ding ding ding! If you want to defend in depth - more power to you. If the way you're "defending in depth" is mostly not adding security, and is actively making the product less useful... I'm going to call it shite. If you blindly say "defend in depth" without actually... you know... evaluating what that defense does to the product as a whole, you're doing your job poorly.
  - jameshart 3y ago
    The rules of engagement on this site call not for radical candor but for taking the most charitable interpretation of someone's words. Maybe the OP wasn't blindly saying 'defend in depth'? Maybe they were advocating for evaluating what that defense does to the product as a whole? If they were, is their attitude worth describing as cancerous?

User23 3y ago

While security and usability are in some sense opposite poles of a continuum, it’s not strictly a matter of tradeoffs. It’s easy to imagine a decision that considerably decreases the usability of a system without appreciably increasing its security or even decreasing it.

Nemi 3y ago

I couldn’t agree more. Security is almost always user hostile (speaking from a UX perspective). I am NOT advocating that we remove security for obvious reasons (a hacked app is also user hostile). HOWEVER - if we can just acknowledge that security is antithetical to an easy to use, user friendly app then we can make appropriate decisions moving forward. One of my favorite sayings is “if you are not careful, you are going to secure yourself right out of business”. Ease of use is a real thing, and if you don’t figure out a way to make a secure app that is also very easy to use, someone else will and your pleas of “but it is not secure” are going to fall on deaf ears. Honestly, baseline security is part of “essential complexity” https://ferd.ca/complexity-has-to-live-somewhere.html https://ferd.ca/complexity-has-to-live-somewhere.html. Essential complexity can’t be removed, but it CAN be moved around. Right now we are talking about the essential complexity of managing security through managing a user’s session length. The advocated solution is to make sessions short so that they expire quickly. This seems to remove all “accidental complexity” so that we are only dealing with the essential complexity. But this is misleading. There is still complexity in juggling those short sessions. As a designer you think this solution is simple, but what you have done is moved that essential complexity over to your users. THEY must now manage the impact of short sessions. The complexity does not go away, you just moved it to your users, hence it is user hostile. The trick then, if making the best product is important to you, is to figure out a way of letting users have long sessions but managing it on your side. This seems to argue that you are making your system more complex by adding accidental complexity (which is generally a bad thing). But really what you are doing is moving some essential complexity away from your users onto you. You lower their burden. This is how you make competitive applications.

pxc 3y ago
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.
- Nemi 3y ago

rrrpfb11 3y ago

> Security is ALWAYS (fucking always, yes really - fucking always) a tradeoff. It’s helpful to me that ACLs prevent me seeing other users’ files. I’m not trading anything off that I’m aware of.

horsawlarway 3y ago
> I’m not trading anything off that I’m aware of. Really? Really???? You're not, say... having to manage ACLs, and having to run a system that can enforce ACLs? Because both of those are tradeoffs. They might be "completely sane and reasonable" tradeoffs! But they are still tradeoffs. Also - in a more blunt way: Simply not being able to see other peoples files was considered a pretty big negative in some computing crowds when it was first enforced. That's a huge tradeoff: You're sacrificing visibility for privacy. I think that turned out to be the correct tradeoff in most places - but to be clear - you absolutely are losing a feature to gain a feature.
- pxc 3y ago
  > Really? Really???? You're not, say... having to manage ACLs, and having to run a system that can enforce ACLs? In this case, it's a more user-friendly tradeoff, because those burdens can be borne by the infosec staff and other IT staff rather than end users. I'm happy when I can arrange things that way for my own users for sure.

paulddraper 3y ago

> A short compromised session is still a compromised session. The duration usually does not prevent the attacker from achieving their goal. Why "usually does not"? The stolen hard drive, leaked data, etc. can happen at any point in the future....one minute to one year from now. For most of those times, a short session will prevent the attacker from exploiting it. > The vast majority of ways to compromise a session already give you access far beyond that session itself For the local system, yes. But not the for the remote system.

ilyt 3y ago
Stolen hard drive is rarely what you defend from, and arguably might completely not matter if say their short lived session is dead but long-lived password manager one is up. Exploits owning software on machine are far more common than machine itself being stolen. I'd also argue that tying re-login to the sensitive actions is far better way to fight it. Basically have long session for nondestructive actions but short for any potentially harmful ones like changing payment options.
- paulddraper 3y ago
  Stolen hard drive = Stolen laptop/phone/tablet
  - Too 3y ago
    Or decommissioned drives. I’ve seen businesses put used laptops straight up on second hand market, without barely doing basic formatting of the drives, unencrypted. Even less so on private market. Heard from security friends also that there are examples of attacks that succeeded thanks to drives found in trash outside enterprise.
horsawlarway 3y ago
> For the local system, yes. But not the for the remote system. This is fair, although you've picked a specific case where the local system would not likely access the remote system again after compromise (because theft removes access for the normal user) and an expired session might be helpful as security. But the other thing about theft is that it also immediately alerts the user, and having a simple "Sign me out everywhere" button is a more robust solution that causes much less user pain and mostly accomplishes the same result. As for > one minute to one year from now. I'm not arguing for indefinite sessions. I'm arguing against short sessions. Rotate it after 30 days if you want (or 5 days, or 1 day - just don't do it every 15 minutes). It'll catch 99% of the cases you're thinking about solving, and it's literally 3000 times less annoying for your users while being nearly as secure.

cortesoft 3y ago

> 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. The worst hack at a company I worked for was caused because an old server that was supposed to be decommissioned was left plugged in and connected to the network… a good time later, a hacker exploited a vulnerability in an unpatched package on the machine and got in (since the server was supposed to be decommissioned it was not patched when the rest of the machines were patched). The hacker used old credentials on the machine to gain access to other machines in our network. If we had been rotating credentials more often, this would not have happened. We had systems in place to patch and maintain our machines, but once the machine got lost in our inventory management system, it was forgotten about. It wasn’t monitored anymore, and other protections lapsed. This category of exploit is prevented by credential rotation, because this type of exploit is only possible if a system is neglected.

edejong 3y ago
It could also have been prevented by… not using user credentials on a server to access services? By doing regular checks on your inventory? By using IDS on your complete network? But not trusting your network? (Zero trust security). By regularly simulating attack scenarios and then check your readiness? By implementing ISO27002?
horsawlarway 3y ago
> This category of exploit is prevented by credential rotation This category of exploit is prevented in a huge number of ways - not a single one of them is "make my user's cookie/token sessions 15 minutes long"

tlarkworthy 3y ago

When I think of short session expiry I think that access_tokens have a limited timespan so if they get accidentally logged the remote end or the person is fired their access lapses. This is a good idea. If we are talking about bounding the lifetime of a refresh token, I agree with the articles, but that is not what I think of when I think about credential expiry. Credentials that you send to third parties should be short lived. I think without that underlying distinction the article is dangerously confusing. Time-bound credentials have many useful features.

theamk 3y ago

The shorter tokes are useless by themselves; but if combined with proactive security, they can make a real difference. Some concrete examples, based on the places I worked in, which provide support for at least not having infinite expiration: - Attacker steals Google token from regular employee.. What can they do? No, they can't "make themselves admin, or wire all your bitcoin to their account" because such things are not available for regular employees. Nor can they use email to take over account because all stuff that matters uses corporate SSO without automated password resets. So all they have access to corporate google drive, which has few terabytes of not so-valuable-stuff + important documents somewhere. With long-living token, the attacker has plenty of time to browse around and download valuable stuff, perhaps even do it slowly so it can fly under radar. But with the shorter token, this does not work: downloading everything will take too much time / trip the alarms, and manual browsing is not fast enough. (I can imagine some sort of sophisticated AI system which auto-downloads interesting docs, but I am sure most attackers have nothing like this) - Attacker steals AWS credentials -- again, they either have to be fast and get detected (there are alarms on unusual high download rate) or go slow and worry about token expiration. Even if they manage to steal important data, at least the expiration will force them to use faster methods more likely to trip the alarm. Even with the full machine compromise, the short-lived tokens are useful. A npm package which steals all tokens once, at the install time, will likely go undetected. A npm package which installs a persistent backdoor will be much easier to detect.. So having a long-lived token makes attackers' lives much easier.

jameshart 3y ago

> 1: A short compromised session is still a compromised session. But an expired compromised session is not a compromised session. If a session cookie/ID is compromised after it has expired it is no use to anyone. But if a session cookie/ID has no expiry built in, then it remains an open compromise risk forever. Situations where we can expect the session identifier and the context in which it is stored to reasonably be under the control of the user for a short time - while they are actively using a site, say - but where it might not remain under their control after they've finished using it, are a real part of real threat models. If I have some cross-site-request-forgery phishing scam that works on users who are logged in to a bank website, that requires them to have an active session at the time they open their email, or visit my site, or whatever... if their banking sessions time out after 15 minutes of inactivity, they are less vulnerable to that threat than if their browsers keep them logged in all the time.

littlestymaar 3y ago

> 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! Yeah, as the Rust saying goes “The safest code is code that doesn't compile”

dang 3y ago

Can you please not post in the flamewar style to HN? I realize it's the tradition in some online circles, but it's not what this site is for, and destroys what it is for. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.