17 ms·

Short session expiration does not help security

• eurekin 3y ago
  Phew, now I will bump session time to a week, since shorter ones were bothering me a lot. Thank you! :D
  • ehutch79 3y ago
    A week? Here i was thinking 8 hours would be a luxury.
    • marcosdumay 3y ago
      I fought a lot at work until I got our sessions times extended into 2 hours (they were 20 minutes).
  • BillinghamJ 3y ago
    Why not a year? Or forever?
• 0bsecurity 3y ago
  If an attacker steals a session cookie with XSS or session fixation, the attacker immediately gains access to a valid session and can keep performing requests to keep the session alive. An absolute timeout would limit the amount of time the attacker has, but realistically this wouldn’t really hinder any attacker. It is a lot harder to obtain valid short term tokens than it is to obtain long lived tokens. The insecurity of long term tokens is demonstrated by the many Elon Musk crypto scams found on Youtube. I do agree that it is always a question of risk/reward. But to argue against it by saying short term tokens don't provide any added security, because a hacker can still gain access to a valid short lived token is disingenuous.
  • jan_Sate 3y ago
    This. It has to do with the window of time that the attacker could access the session. If a service is meant to be used, says, once every 3 months, setting the session expiry to 7 days would make the usable attack window 7/90 = 7.8%. However, if the expiry is infinite, the hacker could just access the session any time. It's also much easier to obtain an active session token than to configure a tool that obtains the token of the future logins. Perhaps it doesn't matter that much if the service is meant to be logged in all the times tho.
• _tk_ 3y ago
  Hand waving away the threat of application use on shared devices seems a little over confident to me. This is probably not a threat for company devices, but it is clearly a threat in other environments, i.e family members sharing a device. While some users might expect to be logged in all the time, others expect to be logged out after they close a web app tab. Session expiration should be application specific. Google's sessions do not expire, so that more user data can be collected. That is clearly more valuable to them, than compromised accounts due to session hijacking. Them doing it, is not a great use case for others, because their value proposition is entirely different than for most other web applications.
  • horsawlarway 3y ago
    > Google's sessions do not expire, so that more user data can be collected. That is clearly more valuable to them, than compromised accounts due to session hijacking. Them doing it, is not a great use case for others, because their value proposition is entirely different than for most other web applications. I think this is a pretty bad take. Google runs some very sensitive applications for paying enterprise customers, and they still tend to not expire sessions. I also really don't like Google as an ad company, and I think my trust in their judgement has fallen precipitously over the last decade, but I find it hard to compare them to someone like Microsoft and say they're doing worse on the security front (I don't think they are).
    • jacquesm 3y ago
      Both Google and Microsoft have world-class security teams. But Google is run in a more effective way (so fewer instances of the right hand not knowing what the left is doing) and has less legacy to lug around, it also suffers less from the innovators dilemma (for now, at least). It makes a big difference if your stuff has been designed as a web based service from day #1 or if you are required to talk to anything and everything on prem and off prem as well as in the cloud. The attack surface of a typical Microsoft enterprise product is absolutely gigantic and the fact that they do as well as they do is something to be appreciative of. That said I don't want their stuff anywhere near my company.
    • 3y ago
• theresmoretoit 3y ago
  https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-token-protection https://learn.microsoft.com/en-us/azure/active-directory/con... Those “sessions which never expire” do, in fact, expire. It’s just that there’s more to it than time. The author should read up on the reasoning behind primary refresh tokens and session tokens.
  • neolefty 3y ago
    They also expire faster when suspicious things happen, such as your IP address changing. Auth providers are pretty quiet about what they find "suspicious" — some are obvious, some are clever.
• deleted 3y ago
  [deleted]
• lapcat 3y ago
  Someone please tell Apple, because they're the worst at expiring sessions. This (among other reasons) makes the developer experience terrible.
  • toddmorey 3y ago
    On what services? I’m not an iOS dev, but I just haven’t been hit with this on apple services as a user.
    • BillinghamJ 3y ago
      On all their websites. Microsoft is quite a bad offender of this also.
      • GoblinSlayer 3y ago
        IME github session is almost eternal.
        • BillinghamJ 3y ago
          More Microsoft-branded then - GH's current session handling largely predates Microsoft
        • throwaway03626 3y ago
          It's possible to connect repositories / organizations to an external SSO. At my work place I have to re-authenticate several times a day. Luckily it usually doesn't require me to login at my work account each time and just redirects back automatically, but it adds an extra layer of protection. If someone gained access to my Github session either physically or externally it would not be enough to access my work. I have these layers of protection between the web page and the actual code. 1. Github password 2. Github MFA 3. SSO password 4. SSO MFA If an attacker wants to be successful, they probably need to actually use my machine as I suspect that both Github and the auth solution at work checks ip-addresses and other things that they would also need to get hold of. In that case they probably have complete control of my machine anyway and can do what they want.
• klodolph 3y ago
  > 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
• sjmulder 3y ago
  What I wonder is why do we apply such different standards/expectations to web and non web apps? E.g. desktop Slack doesn’t ask me to log in all the time. Are web app tokens that much more easily stolen? What about Electron apps then?
  • Ajedi32 3y ago
    I think it's just that users are more likely to sign in to a website on a shared computer than they are to download, install, and sign into an app on a shared computer.
  • gabereiser 3y ago
    Often it’s because your JWT hasn’t expired, your IP matches previous, and so you’re authentic. Local storage is local storage whether it’s electron or browser. If your JWT was close to expiry and your IP address is different and your user agent or headers are different then it may force to re-authenticate.
  • throwaway03626 3y ago
    One difference is that Slack would not work if it logged out automatically after 15 minutes of inactivity. They would lose most of their customers. The only realistic risk to the user from Slack's point of view is that when the user walks away without locking the computer, someone might read or write Slack messages. Sensitive applications still lock after X minutes of inactivity even on desktop, because the impact of someone else using your computer carries too much risk. One example of this is password managers, where they sometimes require a password or a biometric to unlock after a short period of inactivity. You'll see the same pattern in web applications. I haven't used the web version of Slack in a while, but I remember that it didn't force me to login that often. I think one of the reasons why many choose to have a short session expiration time is that they either can't or don't dare to do a proper risk assessment and just does what their competition seems to do. There may be technical reasons too. Web applications do have a higher risk of accidentally leaking passwords through low security and hostile actors. Reducing the TTL may not fix the issue, but it will at least reduce the window where an attacker can make use of a stolen token. It may not matter much if you have a dedicated attacker, but it at least adds some resistance. Creating a secure application takes time (acceptance from business) and experience (junior developers) and many don't have either.
• Nextgrid 3y ago
  In a lot of cases, short session expiry is used as a hack around subpar authentication standards such as SAML/OIDC where there is no reliable backchannel for the identity provider to tell the service to expire sessions (following a credential change, user being deleted, etc). The short session expiry is used as a workaround to force the third-party service to regularly check-in with the identity provider, thus placing an upper bound on how long IdP-initiated changes take to reflect on all third-party services.
  • pcai 3y ago
    This is correct, but its uncharitable to call it a "hack" in many contexts. In oauth, for example, the access token / refresh token concept is literally spelled out in the spec. It's not a workaround, its how you implement eventual consistency in a loosely coupled system where the IDP can't push updates to clients because it doesn't know all of them by design
    • jmull 3y ago
      Hang on, we're talking about user sessions and you're talking about access tokens. Short expiration of sessions is bad because of the terrible UX. Access tokens can be refreshed without user interaction, so it's not the same issue there.
      • Zetice 3y ago
        "Session" here is the word used for the duration in which an access token is valid. You may be talking about UX, but the submission is talking about access tokens.
        • kyle-rb 3y ago
          The article specifically mentions the need for users to re-enter their username and password as a downside of short-lived sessions, so I think the author's definition of "session" extends as long as the refresh token lasts. I think that most of the non-short-session examples — Google, Microsoft, GitHub, etc — are using an access token + refresh token pattern.
• amelius 3y ago
  Also, not respecting your own "Remember me" checkboxes does not make happy customers.
  • kevlened 3y ago
    This confusing wording has always bothered me. Should "Remember me" keep me signed in, or just remember my username the next time I need to sign in?
  • joshstrange 3y ago
    My pet theory on this is developers never test it and QA rarely do either. Both groups are logging in/out constantly and if that checkbox doesn't work it's easy to fob off as "maybe I didn't check it?" or "my account switching broke it but that's a special case". Every time I have to login again to a website that I told to remember me or "trust this computer" I get frustrated and then immediately think "Ehh, I understand how this happens". In a time when a password manager is nearly a requirement it's not the end of the world but it still bugs me since I really don't think most of my sessions have any need to expire unless I explicitly log out (or void all my remote sessions).
    • ilyt 3y ago
      You'd think simple log in/log out test would be trivial to automate...
• chpmrc 3y ago
  Is there a list of "security advice that doesn't really make sense but we keep following just because"? This is a great one, another good one is regularly changing passwords. What else?
  • allanbreyes 3y ago
    NIST dropped the password change recommendation a while back [1] but it still lingers on. The staying power and long tail of this deprecated advice is unfortunate, to say the least. I don't personally agree that short sessions is bad advice, but Phil Venables has an article that you might enjoy, "Ceremonial Security and Cargo Cults" [2] [1] https://pages.nist.gov/800-63-FAQ/#q-b05 https://pages.nist.gov/800-63-FAQ/#q-b05 [2] https://www.philvenables.com/post/ceremonial-security-and-cargo-cults https://www.philvenables.com/post/ceremonial-security-and-ca...
    • rspeele 3y ago
      My experience with security auditors from big firms is that they have a checklist including recommendations like 90-day password changes, composition rules, and so on, and will probably never get rid of those. You may be able to explain to the assessor that "we don't force password changes because NIST no longer recommends it", and they may be sympathetic, but they are still ultimately going to deliver a report that you got dinged on two items because you answered those parts of their questionnaire "wrong". I have had issues raised for a site having a robots.txt file. NOT that there was a sensitive URL listed in the robots.txt file, or that we were using it to try to hide stuff that wasn't locked behind authentication. Just that we had one at all. It ends up being way easier to just get rid of it and comply, than try to explain to multiple people at different levels of management how robots.txt works and how it could be associated with vulnerabilities due to misguided usage while also having NOTHING to do with security when used properly.
      • throwaway03626 3y ago
        Reminds me of the anti virus software at work many years ago that did not allow me to download a password encoding library, because the filename contained the word "password" I've also experienced automatic security reports that complain that the configuration file contains the word "password" (as in "database.password="). I had to argue with them that we did not actually store passwords in Git as they could clearly see, but that it was set using a environment variable by a secrets manager when actually running in a container. Next time we had a similar use case we would just give it a different name to avoid this complication
• ideksec 3y ago
  This article makes so many unfounded assumptions in order to make a point. > Presumably they are going to immediately make themselves admin, or wire all your bitcoin to their account. Attackers running scams like a sophisticated BEC will lay dormant for long stretches of time to gather information before acting. Sure, they can export the emails and set up auto-forward rules to maintain visibility when the session expires, but they've now made a lot more noise to detect on. I've seen threat actors view mailboxes once a day for months before they launch this scam. > Also, it would be better to protect against this by securing the logs or using hard drive encryption. Of course it would, but often it's not. It's that simple. It's crazy to think the person responsible for writing a secure app is also the one making decisions on endpoint encryption. > some applications are used strictly within an company from company devices Some are, lots are not. This reads like someone who has worked in enterprise environments with well funded security teams, not a small business with one IT guy running the show. > But even then, the attacker could install a browser extension that sends your credentials to them the next time you log in. This contradicts the rest of the article. Why is a company securing logs, encrypting disks, locking down where users can access apps, but then allowing anyone to install browser extensions? I agree that short sessions are not the quick fix that some devs make them out to be, but the author is ruling out a perfectly acceptable control based on an imaginary end user setup.
  • jabroni_salad 3y ago
    I recently had a BEC on my desk where they had gained access months earlier to a real estate agent's mailbox. They took the time to create perfect forged documents and understand the agent's workflow. Finally it was time to tell a buyer where to send their Earnest Money and the actions were perfect. They made a mail rule that captured the RE agent's outbound message and then sent their own, an exact replica with just the account number changed. Even if the buyer had called to verify the message it would have been fine because the agent really did send a message. Of course finance people are used to stuff taking an arbitrarily long time (partly the users, partly the system) so they were able to do this several times before anyone raised the issue of MIA transfers. Oh and we don't know the exact date of the compromise because the customer was not paying for good log retention from microsoft or exporting them to any kind of collector. We were able to uncover a lot but I wonder how this goes for indy RE agents that do everything out of AOL or whatever.
• bell-cot 3y ago
  Yeah, mostly true. But were you figuring that the short expirations were for actual security, or for theatrical security? They can be extremely useful for the latter.
• MattPalmer1086 3y ago
  There are two use cases here which are different. Inactivity session termination mostly just protects against someone using your device if you leave it temporarily unattended. Absolute session termination is a different control, which protects against compromise of the session token. So someone who hacks the device and gets the session token can only use it for a period, after which they would need your credentials to get another one. This is usually longer than inactivity termination.
• gabereiser 3y ago
  Neither does “Your password cannot match your previous 1,000 passwords”. Let’s just keep everyone’s password and previous password around in a database shall we?
  • 8organicbits 3y ago
    That usually works by storing the password hash, not the password itself.
    • gabereiser 3y ago
      yeah, definitely not advocating keeping plain text passwords, ever. But previous history of hashes is bad too if the database is leaked.
  • vel0city 3y ago
    You don't need to keep someone's plaintext password in the database to compare. Just re-calculate hashes against historical hashes at new password time. If the hashing process is secure keeping a few old hashes isn't really a security concern, especially if people are actually using unique passwords. Now, normally this is tied to an automatic password rotation policy, because allowing a previous password completely undermines a rotation policy. The real thing to complain about and attack are these rotation policies, which are probably more harmful than helpful.
    • godshatter 3y ago
      I have seen sites that complain if your password is too similar to a previous password, and that shouldn't be possible with hashes. So who knows of the sites that look for exact matches are looking at the hashes or not.
      • vel0city 3y ago
        Systems like that probably do have some form of plain text password history which is very wrong. They might also do some basic common transforms of the password (Increment the numbers, did the hash match? Decrement the numbers, did the password match? Swap case around, did the password match?) but I do agree that's probably a pretty big stretch versus taking the easier (and worse) way to make that anti-feature. I'm not saying that everyone does it right, I'm just saying having a password history enforcement does not require them to keep plaintext passwords. You don't need to "keep everyone’s password and previous password around in a database" in order to have some form of password history enforcement.
• briHass 3y ago
  It's worth noting that many services that offer longer session length also have tools for managing those open sessions and alert emails that geolocate IP addresses using those sessions. I'm sure the big boys do all kinds of statistical (AI if talking to marketing) analysis on session usage metadata (current IP, browser fingerprints, time of day) to try to determine if a session token/cookie has been compromised. All that is a lot of extra effort and UI work for a web application that doesn't have the same immediate access expectations as a web email client or social media. Besides, many users use a password manager that autofills, so login isn't that painful as long as the 2FA persistent setting is respected.
• adrr 3y ago
  Browsers need to provide a way for sites to query if the device has a pass code or not. The lost device threat is a top reason for short session cookies.
  • computerfriend 3y ago
    If you control the device you can spoof whether it requires a passcode or not. Unless you go down the user-hostile rabbit hole of device attestation.
• quirkot 3y ago
  > Are shared computers without user separation a thing? If so, these shouldn’t be used to access web applications with sensitive information at all Shared computers at the library are still the only way some people can access the internet. For others it's the only way they can navigate sites that aren't mobile friendly (gov't sites, etc)
  • rrrpfb11 3y ago
    [flagged]
• deleted 3y ago
  [deleted]
• bombcar 3y ago
  The proper way to handle the problem is to tie session IDs to more than just a cookie or other fixed value; so that if they get exfiltrated they cannot be used without reauthenticating. For example, the Session ID becomes "IP address + session token + browser ID" or something, then if I get your token, and even if I can mimic your browser fingerprint, I'd still have to be coming from your IP.
  • 8organicbits 3y ago
    Careful about doing this. Laptop and phones change networks. If my wifi is weak you'll see my phone switch to data intermittently. Forcing me to re-auth every switch would be painful. Some VPN providers also change IP addresses regularly (I've seen <1 minute between switches).
    • bombcar 3y ago
      You can adjust it to accommodate this, by allowing more than one single combo to be "legit" but it does add extra friction. However, when combined with other things it can at least let "my browser, at my home on my fixed IP" not have to login every ten minutes. Other systems handle this by only doing the "session detailed check" when you perform privileged activities.
    • grishka 3y ago
      Also people in countries where the government censors the internet often use VPNs to bypass that censorship, so their IP address might change many times a day, including jumping to a different country. IP addresses should really not be used for anything beyond packet routing.
  • eli 3y ago
    This is going to fail and break sessions for users way way more often than it's going to stop a bad guy
• coding123 3y ago
  The threat model is extremely different for different types of websites. Banks often look at a variety of shit, ip country and often buy off the shelf systems hardened around faking tools. I don't care what Most websites for security (to some degree) except my bank and my Gmail.
• onetimeuse92304 3y ago
  In real world, security is done by a bunch of nearly clueless people hoping to put enough hard enough roadblocks to make it practically not worthwhile for you to hack in. If you don't have mathematically secure solutions, session expiration and similar are the imperfect tools you use to solve your problem. One beef I have with short session expiration, though, is that in many cases it causes people to degrade security. This happens when people get annoyed by having to frequently provide their credentials and rather than enter credentials securely, use even more insecure workarounds.
  • klodolph 3y ago
    > One beef I have with short session expiration, though, is that in many cases it causes people to degrade security. One counterpoint—if sessions last too long, then I forget the password, and reset the password. If sessions are too short, then I choose an insecure password. Neither option is great for security! Talking about systems for which a password manager doesn’t make sense, like your lock screen password.
    • konschubert 3y ago
      If you're remembering your passwords then you are probably using insecure passwords or are re-using passwords across multiple services.
    • GoblinSlayer 3y ago
      What you don't like in the first option? If you need password reset feature, then it's necessary. If you don't need it, then remove it.
  • lucascantor 3y ago
    This is why I prefer short sessions and requiring frequent, passwordless, biometric authentication. Still relatively low friction for the user, and no password to remember or forget, while still reasonably high friction for an attacker.
• irrational 3y ago
  I use one website semi regularly that has what feels like a 5 minute session expiration, but is actually probably 10 minutes. The session expires even if you are actively using it. Drives me nuts. But not nuts enough to write in and complain. Maybe I should send them this article ;-)
  • nidble 3y ago
    Let me guess... is it a bank? One of mine's does it (expires session after a few minutes, even actively using it). I find that bank websites usually follow completely opposite ways regarding to security than any other industry: very short passwords, only digits, not encrypted in db (some sites ask for single positions), mandatory password input by virtual keyboard, cannot use password managers, not using 2FA or only allowing SMS instead of TOTP or other methods, etc...
    • rrrpfb11 3y ago
      Re single positions, my bank requires a password (which one hopes is appropriately hashed and so forth) plus a challenge to supply requested offsets into a secret phrase. That mitigates I suppose against over the shoulder attack. And they have fewer requirements of the phrase so maybe it’s less likely to be written down? I’m curious whether there’s a technical means to allow the challenge by offset without storing the phrase plain text. I’m challenged for four positions - in theory it could store hashes of all possible four offsets, but is there a better way?
      • GoblinSlayer 3y ago
        Split the secret into characters then compute verifier bytes for each character: verifier[i]=hash(pepper,salt,i,secret[i])[0]
  • eclipticplane 3y ago
    Is it... American Express? It's the only site that will log me out _while trying to pay my bill_. And forget trying to use American Express Travel. I have written in to complain, but have only gotten "It's for security reasons" hand waving in reply.
• avodonosov 3y ago
  > You forgot to lock your computer when you went to lunch, and the attacker sat down at your desk and gained access to your machine. > In this case, session expiration may prevent them from gaining access to your session, if they weren’t fast enough. However, they now have access to your email, ... Only because GMail sessions never expire now.
• deleted 3y ago
  [deleted]
• WhitneyLand 3y ago
  This one seems prone to bias. Out of all the people disagreeing in the comments who actually takes a position against self interest? 1) Security is more your focus than UX, but you agree with the article. 2) UX is more your focus than security, but you disagree with the article.
  • thayne 3y ago
    Security is more my focus than UX (although I am not myself a "security professional"), and I neither agree nor disagree with the thesis of the article. I think the right answer is the classic "it depends". Specifically, it depends on how bad it would be if a session token is leaked, how the rest of the authentication system works (can session tokens be revoked, what is required to refresh a token, how long is the absolute expiration of a token, etc.), and even whether the user is using a public computer or not. That said, the arguments in this article makes many dangerous assumptions. Such as assuming that users never use a shared computer (like say the computer in a library), and that you can completely reliably avoid tokens from ever accidentally getting logged.
  • GoblinSlayer 3y ago
    Short timeout is neither security nor UX, it's security theater to cover the owner's ass when something happens.
  • nottorp 3y ago
    What's security and what's security theater? Is XSS a fact of life that needs to be protected against or a fundamental flaw of the protocols we currently use that could be fixed at the root if it didn't make web development more expensive/inconvenient?
  • BeefWellington 3y ago
    The mistake is in thinking security is a separate domain from UX. While expertise in it may be, it applies everywhere. To draw a comparison here, should we assume that the author advocates for phones or desktops which do not automatically lock after a set period? It's a similar threat vector (unattended phone/pc) in the physical world. I'd assume no, because the specifics of that threat model are different. This is true of other software as well. UX and security are only at odds in the grey areas. I'd wager most people posting here -- regardless of affiliation -- would be upset if their web banking solution didn't expire their sessions for days.
• 8191 3y ago
  Can someone associated with PayPal being that article to some decision maker’s attention, please? I believe their session timeout is fixed to 5min of inactivity, which you easily reach when doing some accounting tasks with PayPal purchases. Renders PayPal to the most annoying web app I frequently need to use…
• qwertox 3y ago
  My banking site has an extremely short timeout, like 5 minutes but feels like less, which is really burdensome when you're looking at stock data while trying to read news about it. So I had to create a Tapermonkey script which reloads only a specific page of the bank every 30 seconds and I move that tab somewhere where it doesn't disturb me. How is any of this improving security?
• SoftTalker 3y ago
  If expiring sessions are not important, we can go back to using http authentication on the web and not have to build our own. Yay! Oh, we still need 2-factor auth? Darn.
• dobin 3y ago
  "Thank got we set the session timeout to 5 minutes, or we would have been compromised" - no one ever. I am in the 10-hour session timeout camp (or at least 4h, so you only have to authenticate twice a day). Session timeout checks are same sort of checkbox tests auditors (and pentesters) like, like password policy where you have to change it every 90 days. And about as effective. What's missing in the article is the difference between soft- and hard session timeout (Soft: Reset upon user activity. Hard: session gets killed after X hours regardless of user activity).
  • nottorp 3y ago
    It really depends. I would certainly comment less often on HN if it logged me out at 4 hours. For my online banking it's okay if they kick me out after 15-30 min.
    • CSSer 3y ago
      Agreed, but is it about the way you use online banking or is it about security? I think it's interesting to consider because at the point where "security" starts to impact UX, you have to really scrutinize the difference between what's actually making an impact on your security and what's just theater.
    • nofunsir 3y ago
      It literally prevents me from banking well. It’s not enough time to do banking tasks that require analysis or reading.
• deleted 3y ago
  [deleted]
• pharmakom 3y ago
  short sessions exist to enable token revocation that does not require a central sync point (aside from time servers)
• devonkim 3y ago
  The point of short sessions last I saw is not necessarily for technical reasons but for helping with legal reasons. That is, it means to lawyers that an authorized user could not have performed actions outside of a certain time window. This makes the discovery period for legal proceedings substantially faster.
• njarboe 3y ago
  "short session timeouts, such as after 15 minutes of inactivity" I wish my bank, credit card, brokerage websites gave me 15 minutes of inactivity. It seems most have set it at about 5 minutes. My finances are not trivial so I am often logged out when paying bills, figuring out my budget, planning a big purchase, etc. I don't think there is any way to set it to my preferred value.
• hipaa_eng 3y ago
  We use short sessions to protect patient information from unauthorized access in systems that we build. Yes, you shouldn't leave your machine unprotected but real humans do. Sometimes, you may trust someone with access to your computer but they shouldn't necessarily access certain protected systems. Especially in HIPAA-land, short sessions are a really effective way to make systems usable while still limiting how much damage can be done even accidentally.
• avodonosov 3y ago
  > Current security advice is to use quite short session timeouts, such as after 15 minutes of inactivity. I do not remember a web application with 15 min timeout. Some banking apps have short timeout, even shorter than 15 mins. But normal apps usualy had 30 mins, I think. Many simply relied on the browser session cookie - on desktop that meant until you close the browser. 15 mins would be inconvenient. Aslo, most web apps with limited session duration had the Remember Me checkbox, that extended the session cookie duration to about two weeks. So, the user experience costs are not so big, as the article presents. > However, most mobile apps and big web applications such as Gmail or GitHub don’t adhere to this. You can be logged in seemingly forever without authenticating again. Are these insecure? Do Google and Microsoft know better than NIST and OWASP? I can not compare to NIST and OWASP, but I do not see Google and Microsoft as ideals everyone should blindly follow. I suspect, these companies started to use endless sessions - a security degradation imho - after they adopted two factor authentication. Authentication process had become too annoying for users, and corpanies introduced endless sessions - zero factor auth. Similar as an often password rotation was recommended as a best practioe for years, and then it was realized as making more harm than good, because users are annoyed and take shortcots. The two factor auth lead (I suspect) to zero factor auth. A similar claim in the article, about short sessions, is not supported by evidence: > However, short sessions have disadvantages, both in user experience and in security. If someone needs to log in again every 15 minutes, they are going to make authenticating as easy as possible. That means keeping the password vault open, choosing an easier password, or putting the password on the clipboard every time. Reauthentication comes with its own risks. A shorter expiration time does not automatically reduce the overall risk. Thats not how it worked for me. Sometimes I maybe used the Remember Me checkox, but often I prefer to type password manually - I like to be prompted for password from time to time, to refresh it in the memory. Some people use passwrod managers As a user, I am OK with Hacker News having endless session. But not email. Ideally, I would like each authentication factor to have a separate cookie / token, with its own user-controllable expiration time. So instead of an old Remember Me checkbox to have two Epire In duration inputs. And instead of the Sign Out button, to have the two tokens represented separately, with the expiration interval and remaining time, which I can change / termintate.
• paulddraper 3y ago
  > Perhaps you used the shared computer in the library to access your web application, and forgot to log out. > 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. Yes, it is a thing. I understand you would like it to not be a thing.
  • loneboat 3y ago
    Heh, author gave a perfectly reasonable example of where use might be shared, and immediately asked "Is this a thing?". Like, yes. It is. You literally JUST gave me an example of it. Also this, shortly after: > Are shared computers without user separation a thing? If so, these shouldn’t be used to access web applications with sensitive information at all That "should" is doing a lot of heavy lifting. You don't decide which security controls to implement based on your best-behaved users.
    • BeefWellington 3y ago
      It's not even about behaviour. Some government services switching over to fully digital means there's a cohort of people being left behind. A decreasing number, sure, but a number nonetheless. Effectively the author is saying poor people who need to use library PCs shouldn't get security.
  • powersnail 3y ago
    It reminds me of when I didn't understand why my library account has such a short expiration time. Almost every time I open the library's website, I have to re-enter the password. Why? What's so important about a library account? Who's going to borrow a book on behalf of me? And then I realized that logging into your library account is probably one of the most frequent things on all the shared computers in the library.
  • gregopet 3y ago
    Even if it is a thing - after using a shared computer one MUST log out. If the 15 minute expiration time saved you then you're just damned lucky!
• throwawaaarrgh 3y ago
  Session authentication tokens are effectively a form of credential. Best practice is to expire all credentials after a certain amount of time, because you cannot know for sure all the ways this credential might be compromised or when. It does mitigate risk to reduce the time window in which an attack is feasible / when the attacker might get the credential, and when they might start their attack. Just because you assume that every attacker has access to X, or has root on their machine, or is everywhere always, etc, doesn't make it true. Some attackers don't have a big advantage; mitigating their attacks helps security. In addition, the kind of credential tends to dictate the expiration time. Some don't need to be expired that often. You can also mitigate a lot of the risk by requiring re-authentication to perform riskier actions, like changing email address, or authorizing payment. Combine with other methods like user fingerprinting to force re-authentication if it looks like it might be a different user. If you're thinking "but we don't rotate passwords as best practice anymore, why sessions?" We basically gave up on passwords. It would help security if people rotated passwords, but unfortunately it's such a pain for the users that they end up doing insecure things like writing them down or incrementing a number at the end, so a compromised password tells you what the next likely one is. If they were randomly generated we would absolutely be rotating passwords still.
  • ShrigmaMale 3y ago
    CIA. yeeting people out of their shit every ten minutes cripples availability, we gotta balance. like most things where the person making the call is not the person who deals with it, security ppl are often too aggressive about killing session duration.
• logicalmonster 3y ago
  Just to play Devil's Advocate, short sessions may actually end up being far less secure when you consider that humans are flawed. If you force people to log in to a system very frequently, they might get lax with security and do dumb things like stick "post-it notes" to their monitors with their login info out of frustration.
  • sneak 3y ago
    Device malware, which is common, can't steal those.
    • grishka 3y ago
      But a keylogger has a better chance of stealing the password if the user has to enter it more frequently.
      • sneak 3y ago
        Hardware 2FA is common now among professionals, and is finally widely supported.
• sneak 3y ago
  It helps security tremendously (against local device malware) if you use hardware 2FA, which is now widely supported and is used by the security conscious. So does sandboxing and file system access permissions.
• obblekk 3y ago
  @sama Jk though I intuitively agree, I think this article doesn't really prove its claim. > 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. I would argue shared computers are one of the primary threats deterred by this. Additionally, for the attacker has access to device section, the author points out an attacker could still access email. But, email services tend to be more developed and often have the ability to expire all tokens (or logout all browsers). The exact place short session expiration helps is when the service does not provide a feature to log out all sessions remotely. That would be a better deterrent by far, but may be more complex to build than a default timeout.
• _8j50 3y ago
  I agree with the author but I would add "... but long session expirarion harms security". In the real world, if an infostealer is stealing your session cookies, it doesn't have to be a one time thing,it can send your cookies back on an interval. But speaking of, ssh private keys and user auth certs having an overly long lifetime is as much of an issue. SSH is the worst offender but for the unaware, you can enroll a cert for a windows account and even if the password is rotated regularly (like your super secure hashicorp/cyberark/tychotic rotated service account) that one cert can be used to get kerberos tickets and login/auth just fine, the cert lifetime is usually months if not years. Smarter folks use a CA with SSH but the thing with CAs is you must use ocsp responder for short lived certs because a CRL isn't always feasible, maintaining ocsp for this type of frequent use at scale is no simple matter either. Back to web sessions though, in the cloud and on azuread/o365 stuff (like onedrive or teams), the session token does get renewed every few hours but without any user interaction because the device is trusted. So all a threat actor needs is one sesssion/token and the ability to proxy traffic through the victim host. Matter of fact, my secret yet controversial opinion is that SSO should never be implemented without 2FA period. No exceptions! The cred you manage centrally gets also pwned centrally. A lot of crap like device auth and conditional access policies make SSO very dangerous, if I had a company I would mandate yubikeys and password managers with app specific creds by default and SSO with yubikey where possible. With 1 day expiration as a default.
• jedberg 3y ago
  They way I like to handle session tokens that seems like a good compromise between security and user friendliness: Automatically renew the token as long as the user is actively using the website. I usually use a 12 hour token and renew if it's 8 hours old or more. The renewal requires the use a second token stored locally in the browser so even if you somehow sniff the token off the wire, you still can't renew it without control of the user's browser. And frankly if they have control of the user's browser, they could probably install a key logger anyway. That way, if someone is constantly using the site, they would never notice a logout, but otherwise they might have to login once a day.
  • neolefty 3y ago
    Some big auth providers throw in a few extra signals too. Your IP address changes? That might hurry up expiration a little. Your user agent changes? Big red flag. Etc.
    • ilyt 3y ago
      Another pet peeve is getting logged out just because chrome or FF upgraded in background...
  • skinner927 3y ago
    Do you sign a request with that reauth token or do you send the reauth token? Because if they’re getting mitm then all is lost. How long does the reauth token last for? Is a new one issued when you reauth? As negative as I sound, the system is better than just allowing the regular api token to extend the session. Of the hundreds to thousands of api requests a regular user may make a day, only 1 is the reauth, which is nice. Security is an onion. Every layer is a bit sour and eventually you’ll cry.
    • jedberg 3y ago
      > Do you sign a request with that reauth token or do you send the reauth token? Sign > Because if they’re getting mitm then all is lost. This is true regardless of your authentication scheme, which is why https is important and then you have to hope they didn't just click through a warning and ignore it or have their trust store compromised or.... > How long does the reauth token last for? Until it is reissued. But since the auth token is only good for 12 hours, effectively 12 hours max, since it can't be used for reauth without a valid auth token. > Is a new one issued when you reauth? Yes.
• ryanianian 3y ago
  Killing short sessions would be somewhat nice from a user perspective, but I think this is unrealistic as others point out. Instead, let's focus on what makes short sessions super obnoxious. In theory I don't mind a fast and painless re-auth that doesn't hugely interrupt my flow. But the current implementations seem to be actively user-hostile and intentionally annoying. My company has moved to Okta for most things. Fine. But the session expiration and re-auth mechanism is extremely maddening. It comes out of nowhere. Right in the middle of doing work, I need to re-auth to {jira, github, google suite, whatever} without any warning. Github in particular makes you re-auth to each org independently even if trying to view OSS material that doesn't require auth to begin with. And of course SSO flows break anchor tags in URLs so good luck if you already closed the link that had the necessary anchor information. Then let's talk about Okta in particular requiring three separate pages and clicks for user, pass, otp (because a single form with all three is "insecure" in a meaningful way?). And then not respecting dark mode making an otherwise dark-friendly workflow have flashes of bright light at unpredictable times. Sure, let's make regular re-auth a thing. I'd even do it once every X hours. But come on. Let's make the re-auth schedule predictable (ugh google suite re-auth right in the middle of screen-sharing or doing deep work on a doc). Let me pre-emptively re-auth everywhere all at once in a batch (pointing my finger at you, github). Let's figure out a way to preserve anchor tags (javascript is a thing, sso sites could capture and sso providers could pass this through). And dear god, Okta, please just support dark mode on your interstitials. I view that bright flash of light about 5 times per day now and it raises my cortisol levels and hurts my eyes every time. I know TFA isn't about SSO flows, but SSO flows + short sessions highlight how annoying the end-result of this hodge-podge of auth is for users trying to do their job.
  • dasponge 3y ago
    I definitely agree with you that better warnings and more graceful session timeout behavior would be a huge improvement. It's hard with the current auth standards where the IdP is only in the loop during the initial auth; it'd be on each app to gracefully notify and handle soon-to-expire sessions. That's pretty unreasonable across the large swath of SaaS apps and vendors (given how may have pretty buggy/difficult to integrate SAML implementations). When you throw a CASB or proxy like Cloudflare Access in front of everything then you're fully in the loop, but that's a bit much for a lot of use cases. >Then let's talk about Okta in particular requiring three separate pages and clicks for user, pass, otp That's on your IDAM / Security team and how they've configured Okta/mandated requirements. Okta has fully passwordless, phish resistant, automatic flows with Verify on Mac/Win.
• lr4444lr 3y ago
  Disagree completely. People walking away from public computer terminals, e.g. libraries, are greatly helped by shorter sessions, even if they're imperfect.
  • grishka 3y ago
    This is solved by the "someone else's computer" checkbox in the login form that makes sessions expire. 99% of the time, though, people are using personal devices. 99% of people should not suffer because of the forgetful fraction of the 1% who use shared computers.
  • GoblinSlayer 3y ago
    Crowd near terminals helps there. If a thief wanted to do something shady he will shoulder surfed by many eyes and breathed in the neck.
• cratermoon 3y ago
  I'm going to go with that old chestnut: It Depends. The author gives a variety of scenarios where the session could be stolen, but doesn't really discuss the context and threat models around them. There is no one-size-fits-all. Shorter expiration times might be the right choice in some scenarios, and useless in others. Also, yes, shared computers without user separation are still a thing. Not all libraries have the budget or technical expertise to secure shared computers as well as possible. Also, there's public WiFi, something I'm betting the author uses all the time.
• grishka 3y ago
  ANY session expiration does not help security. Authentication should not involve time. If I logged in, I should stay logged in until I explicitly log out. That's it. The session should live forever or at least several years from the last time I used it. Speaking of internet cafes and other shared computers, they usually are secure enough. All internet cafes I've ever been to run specialized management software on their computers and everything gets wiped the moment your paid-for time expires. In places like universities and schools, people usually have their own domain accounts that reside somewhere on a central server, including their home directory that stores all the cookies and tokens.
  • Zetice 3y ago
    This is an insane take; if your session token is buried somewhere in a log and gets discovered after a few hours, it shouldn't even be remotely possible that it's still valid.
    • grishka 3y ago
      A few HOURS? That's an insane take. What kind of situation makes that possible even?
      • Zetice 3y ago
        Hacker gets in, exfiltrates your log files that mistakenly have session tokens in them, goes through over the course of an hour or two before stumbling upon an admin session token that's still valid apparently. Could easily write a script to find the session tokens and check them for validity. Many have their TTLs directly embedded, no need to touch a server to check, at least for that.
        • grishka 3y ago
          If a hacker is able to exfiltrate log files, what's to prevent them from exfiltrating other things? If they get into a server, they could as well dump sensitive data form the database or do something to gain persistence, like installing a shell or adding their SSH key. If they get into a client device, they could steal more, more valuable data than just some logs — browser cookies, email credentials, app tokens, owner's personal information, all that stuff.
• actuallyalys 3y ago
  The main place I see short session expirations is on banking and financial apps, which seems defensible to me for a couple of reasons: 1) They're used by a wide variety of people, including people who may not own a computer or mobile device, or who may not have a backup device to use when their personal device breaks. This group is probably shrinking—more and more people have smartphones and the remaining people who don't have smartphones are probably also the people without bank accounts—but arguably you want to cater to this group, since they may already be a bigger target for scams. 2) They're very appealing to opportunistic attackers. 3) They're used by people in stressful or unusual circumstances, e.g., when traveling, if they need to make a large emergency payment, or if they're afraid of being scammed. 4) Most sessions aren't very long anyway: checking a balance, seeing whether your paycheck came in, making a single transfer or payment, etc. There are definitely exceptions—15-minute timeouts are very annoying when doing taxes, for example—but it seems like the annoyance in these situations is potentially worth the security benefits. That being said, I don't know if short session expiration is the best solution in 2023. As the article points out, major corporations like Google don't use short sessions, even though their services are used for a variety of sensitive things and they're huge targets. But as briHass pointed out in another comment, they also provide tools to see which sessions are open and use a variety of techniques to detect sessions being misused. I suspect that's the actual best solution if avoiding session stealing is that big of a concern.
  • kccqzy 3y ago
    > major corporations like Google don't use short sessions Ask a Google employee. When I worked there sessions were limited to 20 hours. Beyond that full re-authentication with password + security key would be needed.
    • mynameisvlad 3y ago
      I’m pretty sure they mean for consumer accounts, not their own organizational logins.
    • sss111 3y ago
      Why'd you leave?
• Zetice 3y ago
  > If an attacker steals a session cookie with XSS or session fixation, the attacker immediately gains access to a valid session and can keep performing requests to keep the session alive. Objectively false? If they get the refresh token sure, but even that has an expiration and isn't refreshable in many common implementations. If they only get the access token, then this is completely false; you can't refresh a session using only the access token.
• skybrian 3y ago
  It seems like a shorter session expiration time could help with analysis because you don’t have to worry about bugs that were fixed long ago. The longer the expiration time is, the farther you have to go back in history when thinking about how an old bug might have been exploited. (Similarly for key rotations.) This might affect how long you want to retain logs?
• indymike 3y ago
  From the article: Facebook, Google, Amazon and GitHub have sessions that never expire. In the case of Google, GitHub and Amazon, I routinely have to re-auth. I'm not sure that this is accurate.
• cameronh90 3y ago
  The main reason you would want short user sessions is if you can't be sure whether the end user device is adequately secured. For example, if you're building a banking application, there's a huge monetary risk in allowing someone to potentially leave an open session on an unlocked shared computer. Is this something that we could resolve with browser standards, for example the browser being able to provide some kind of a hint about how well secured the end user terminal is? Not cryptographic remote attestation or anything, just something simple like a header or API that would return some basic information such as whether the user has a screen lock with password enabled and whether the computer is a shared device or kiosk. On Android, there is the KeyguardManager.isDeviceSecure method which provides this sort of functionality.
• unethical_ban 3y ago
  Short aside about session lengths: If you are an app like Chase or Discover, and you intend to kill my app's biometric auth session after say 90 days, please tell me that when I first login manually and at least 7 days before said session will end. I keep my passwords in local password safes, and I manually sync a copy to my phone. It should not be expected by the user to have access to their passwords every day, if they have apps which say "Oh yeah, fingerprints! We trust you!". If I were in the middle of a trip and got logged out of my mobile app without my password safe, I would be screwed, and it would not be my fault, given how opaque the session policy is on these apps.
• throw1234651234 3y ago
  Very tangentially related, but people keep trying to convince me that cookies are somehow safer than JWTs. Is there any truth to this whatsoever? Keep in mind that you can have a "sessions" with JWTs too, though it entirely defeats the point.
• maxvt 3y ago
  > Facebook, Google, Amazon and GitHub have sessions that never expire. They think it’s an acceptable risk. I think they are right. Three of these companies have a strong vested interest in keeping you logged in all the time and to minimize the friction of interacting with their services. GitHub, if you use 2FA or corporate SSO, does expire sessions. Perhaps they make the tradeoff of risk vs convenience for username/password users, as is their right.
• Puts 3y ago
  This is total bullshit. Stolen sessions are being actively sold on Darknet in bulk. If nothing else the best thing that can happen is that they have expired before someone have the time to exploit them.
  • kccqzy 3y ago
    Totally agreed. OP has no idea the scale of account takeover attacks by stealing tokens for any large online service (Google accounts, iCloud accounts, Microsoft accounts, etc).
  • nofunsir 3y ago
    Good idea. Let’s set it to 0 minutes. If they’re not in an active mouse click rhythm just nigh of Liszt, log em out! is what I always say.
• runningmike 3y ago
  “ threats described above are easily fixed” This is not correct. Non tech users do not understand any of this imho.
• bilsbie 3y ago
  Has anyone sent this to openai?
• cypherg 3y ago
  As someone that regularly works with malware, cybercrime and SaaS attacks I strongly disagree with this article. One look at Genesis Market is enough to see why "better auth", "2FA", etc, do not solve the problem of malware on the machine stealing cookies (sessions).
• happytiger 3y ago
  It does when access is on public computers, such as in a library or similar shared terminal.
• fideloper 3y ago
  Short session lengths are often demanded as a thing to do (or provide as an option users can opt into) to remediate “issues” found from security audits. It’s an easy enough box to check and so it’s often checked. That’s why you’ll see them banks and other regulated environments, or on apps that provide soc2 or otherwise have been through security audits (google makes you do an audit of you use certain APIs).
• EGreg 3y ago
  And yet ITP destroys all cookies after 7 days, even first-party cookies, unless your site never uses any other third-party iframes or hosts servers in multiple data centers. But they do it to prevent websites tracking their own visitors without their consent for more than 7 days… I think. So session expire not just to spite you. But the question is — given that the cache is totally cleared, after 7 days, can iOS safari ever guarantee that a specific URL will NEVER be replaced by a server to something else? With non-expiring caching, we could! But now?
• nofunsir 3y ago
  Judging by response quantity and low quality (Some are really defensive), this has really struck a nerve here. 15 min logout on a bank site isn’t even enough time to read a full statement pdf.
• inemesitaffia 3y ago
  It definitely helps with "friendly fraud"
• MrStonedOne 3y ago
  [dead]
• joshuanapoli 3y ago
  It would be interesting to see a test of this idea with some sort of honeypot.
• 1vuio0pswjnm7 3y ago
  "That being said, I don't know if short session expiration is the best solution in 2023. As the article points out, major corporations like Google don't use short sessions, even though their services are used for a variety of sensitive things and they're huge targets." Is it possible that Google might prefer that users stay "logged in" because this allows Google to conduct more data collection, for purposes of supporting its online advertising services business. Perhaps staying logged in is "more secure" for the ad targets that use Google than logging out. Maybe its both, but not in equal measure. Which one would be more important to Google and its shareholders. Would a company like Google make tradeoffs that favour its bottom line. Are there any differences between the core business of Google (advertising) versus the core business of financial institutions. For example, Google's customers are advertisers. The folks that have Google "accounts" for non-advertising purposes, i.e., probably the majority of folks in the world who have Google accounts, are not customers.
• 1vuio0pswjnm7 3y ago
  "Session tokens are pretty secure. The threats described above are easily fixed with other measures, such as disk encryption, locking your computer, or HttpOnly cookies." Or simply log out if a token is stolen.^1 After logging out, the session token is expired. In some cases one can log out non-interactively with a single HTTP request. No need to visit a page in a Javascript-enabled graphical browser and navigate interfaces. One can use a forward proxy to insert tokens for selected sites. This allows one to scrub/disable/clear cookies globally but stil remain "logged in" for certain sites. 1. The problem is the user might be unaware that a token has been stolen, at least until it is too late.
• paulmooreparks 3y ago
  My favorite example of putting security ahead of usability: "Unexpected item in bagging area. Please remove item from bagging area." "Item removed from bagging area. Please wait: an attendant will be with you shortly." This one sets me off because I worked in the self-checkout division. The simplest way for stores to improve customer satisfaction and increase usage of self-checkout was to disable the bagging scale and accept that there would always be a certain level of "shrink," or grocery item theft.
  • r00fus 3y ago
    France has a workable system - you do all interactions with the machine - it doesn't weigh your items - but a clerk oversees you (along with another 3 ppl) and checks your receipt against your bags at the end. Like the Costco receipt checker, it's very unlikely this person will flag anything unless you're suspicious as hell. It's like those "eyes stickers" in Asia - to keep honest people honest.
  • raffraffraff 3y ago
    It depends on the system, but I've seen the weight system work consistently well in one store chain and fail on every other item in another store chain. Perhaps there's a leniency configuration, and some stores set it to "ultra, ultra paranoid" mode?
• breadwinner 3y ago
  If the account is for accessing employer's system then sessions have to be kept short, and users have to re-login every day. Otherwise employees who have left the company would continue to access the system. The reason Google never expires your session is because they want to track your activity and connect your activity to your account. This is not a good system to copy.
  • 0xFF0123 3y ago
    Surely you can revoke a session before it expires?
    • breadwinner 3y ago
      No you can't because you don't immediately know that the user's account has been suspended (assuming you're using an identity provider).
  • noitpmeder 3y ago
    This seems like a non issue... Can't you just invalidate existing sessions/tokens immediately when an account is suspended?
    • breadwinner 3y ago
      If you're using your own password-based auth then you can. But that has its own issues (such as user has to remember to delete account on your system). If you're using single-sign-on then you have a token from an identity provider such as Microsoft or Google, and then you don't get immediate notification that the user account has been suspended.
• lijok 3y ago
  There’s a ton of these pseudo-security measures bestowed upon us by various outdated security benchmarks, which we have to follow or risk losing our certification or regulatory permissions, even though said measures in most cases reduce security. I’m looking at you - Sudoless single-user machine users - VPNs - AVs on servers - Disabled ports - Disabled ota protocols - etc
• BWStearns 3y ago
  The worst offender I’ve seen for this is OnShape. I totally get them suspending the session for GPU usage reasons but there’s no reason I need to reauthenticate 80 times a day when taking 15 minute breaks away from the computer to go look at a machine.
• temporallobe 3y ago
  What’s annoying and completely unnecessary is aggressively short session times on resources that are already behind a VPN and multiple layers of security, such as an RDP session, making you constantly re-authenticate throughout the day if you happen to turn your attention away from it for a few minutes. In fact, having to re-authenticate for multiple services throughout my workday day really adds up.
• InnerGargoyle 3y ago
  somebody tell that to Interactive Brokers man. at least the session should remain active for days trading hours.
• markrages 3y ago
  , and
• pabs3 3y ago
  Authentication should be in every request, using TLS client certificates.