41–50 of 434 posts
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)
Someone please tell Apple, because they're the worst at expiring sessions. This (among other reasons) makes the developer experience terrible.
On what services? I’m not an iOS dev, but I just haven’t been hit with this on apple services as a user.
Very annoying. Supposedly it prevents tracking, but it's just annoying.
> 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 particula…
> 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…
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.
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.
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…
> 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 customer…
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.
> 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 particula…
> 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…
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.
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?
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.
> 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 particula…
Earlier quoted context omitted.
> 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.
> 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 thro…
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.