Short session expiration does not help security

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...

> 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.

"Optimize the application to run the best for all the users first and then adjust the security implementation as necessary. Otherwise, you could DoS yourself by trying to be too secure. "

I think it depends what kind of buisness you are running and what a security breach means for you or your users. If it is a hobby forum, well yes, UX matters more. But if you screwed up security for anything with big money related - you probably want to prioritize security first and not after you lost some billions.

> 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.

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.