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.

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.

GitHub does this too.

My bank does that but also:

* logs out after 10 minutes of inactivity - so doing anything that involved switching between accounting app and it is annoying * not allowing more than one tab open at once - that's just stupid in its entirety.

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

This is our business account so we're moving anywhere from $20k to $200k at a time.

In the spirit of adaptive security, someone moving $100k will probably be fine dealing with a couple extra password / 2fa prompts... but I agree it would be annoying to deal with this for day-to-day (consumer) bill pay. A bank could throw fewer roadblocks when paying a $500 invoice vs. a $50,000 invoice

The workflow I described also is part of a dual-approval model where a finance person sets up the transfer and it's approved by a 2nd person (who's presented with a bunch of authentication/password/2fa prompts, almost to a fault).

But again, I'm fine with it because it's large amounts of money in corporate bank accounts. But yea, agreed it would be annoying and should be toned down in a consumer use case.

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

Okay. I will compare using house to short sessions.

Short sessions is like having house with every doors having a lock and I need to use the keys to get into different room, if I stay in one room for too long, including the shitter. I also need to use the keys to open windows and the oven. And developer going "well, you shat yourself ? That's your fault, should've had keys on you at all times".

That's what short sessions are. Delusional security clowns ignoring usability. It's less than security theatre, it's security circus.

Requiring re-auth to pay some money or delete something important is reasonable stance.

Requiring re-auth few times a day just to browse data in the app is not,

That is a straw man argument. Nobody was saying security should be prioritised over the goal of the product.

Security is just another non functional requirement (mostly) of a product.

To obtain good enough security, defence in depth is still a good principle to follow. It means you are not putting all your eggs in one basket. It often means that each individual control does not have to be perfect or massively over engineered.

So in this case, when short sessions are a clear negative for a lot of products, and we have existing examples of HUGE enterprise companies that have agreed and adjusted those sessions to be much longer for most cases...

I would argue that you are arguing to prioritize security over the goal of the product. Right here and right now - you are literally doing it.

> To obtain good enough security, defence in depth is still a good principle to follow.

I don't disagree! I just think that each "defense" needs to actually be considered on the whole, not as just another bonus to security. Short sessions SUUUUUUUUUCK. They make your product shitty. Users hate them. They don't add a ton of security.

Are there products that should still have them? Sure. Probably lots of products in VERY specific places. Should they be the default everywhere? Sure as hell not.

Don’t prioritize security if the root cause of the security breach is someone is getting access to the session tokens not that the server session tokens are arbitrarily too long. that attack might happen once ever and it doesn’t really matter if they have five or 10 minutes you’re still screwed because they can just go get another session token next time and be prepared.

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.

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

Zero days exist almost every day and there there’s nothing you can do about it. So make sure that what they steal if they do steal anything is a bunch of encrypted envelopes instead of raw pictures.