211–220 of 434 posts
(Similarly for key rotations.)
This might affect how long you want to retain logs?
Earlier quoted context omitted.
> 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…
> 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.
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"
Earlier quoted context omitted.
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.
A few HOURS? That's an insane take. What kind of situation makes that possible even?
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.
Earlier quoted context omitted.
> 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…
> 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 exploite…
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"
Earlier quoted context omitted.
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…
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 th…
verifier[i]=hash(pepper,salt,i,secret[i])[0]
Earlier quoted context omitted.
> * Makes it less likely that when an attacker obtains a session token that is is unexpired. But gives them more opportunities to acquire such token. > * Gives the attacker less time to use a valid session token to move laterally into (potentially) unfamiliar infrastructure. Only if tokens lifespan is counted in milliseconds. Otherwise, the attacker will refresh the session token as soon as they get it, and continue…
> But gives them more opportunities to acquire such token. Maybe, if the session tokens are being acquired by improper logging. If the tokens are acquired via the user’s cookie store, for instance, the total number of session tokens is going to be the same — the user is going to use the applications they use, and the stored session tokens will reflect that. > Only if tokens lifespan is counted in milliseconds. Otherw…
> There are instances where session timeouts/forced reauth are useful and where an attacker could not endlessly refresh the token.
If the token isn't refreshable without a "real token" the "real token" will probably need to be somewhere the attacker can get it anyway.
> 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.
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.
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.
Earlier quoted context omitted.
A few HOURS? That's an insane take. What kind of situation makes that possible even?
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.
Disagree completely. People walking away from public computer terminals, e.g. libraries, are greatly helped by shorter sessions, even if they're imperfect.