Short session expiration does not help security

But, you need to make sure the extra controls are actually providing depth.

I think in some (very narrow) cases, short session times and aggressive reauth do add depth and can be an effective part of a security program.

But, all too often, defense in depth is used to mean:

* Vendors In Depth, whereby every security tool under the sun has to be deployed (or at least purchased) to achieve “security”. Or, worse, the Noah’s Ark model where you buy two of everything.

* Uncoordinated and/or seemingly random layering of controls that either don’t add to the overall confidentiality, integrity, or availability of the system being protected. Or, worse, are positively counterproductive and actively reduce the real-world security of the system.

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

Still metaphorical cancer.

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.

>There is a cost every time a user has to re-authenticate. There is a cost in resources to handle the extra authentications. There is a cost in complexity to maintain and extend the system doing authentication.

I think this is definitely where the security trends in modern IT have gone very awry, as it _is_ extremely annoying to be an end user having to work with modern IT security practices. Off the top of my head:

- MFA everywhere means that if you have any issues with your alternative authentication devices, you are completely locked out of your work and probably your life until you get that resolved

- broad and vague block geo-based block lists means users just flat out cannot access resources depending on where they happen to be, which means service desk tickets, investigations, and ultimately people who cannot access non-sensitive data they should be able to just because of where they are physically located

- CAPTCHAs can lock entire classes of persons out of specific services as the CAPTCHAs aren't easy for these classes to perform on demand

- SSO/SAML authentication pages take you on a whirlwind tour of dozens of randomly generated authentication pages meant to establish and pass your authentication back to a central location, and it makes it impossible to tell from the URLs themselves whether or not it's suspicious or not unless you know the specifics of the system in use; this is particularly bad because this is exactly what it will look like if you click on a spam site in a search result or a compromised webpage. how is a user supposed to know when they've accidentally gotten tricked into a compromised authentication page? the uniquity of SSO for logins is nice, but it also means that as a user, I expect that I can be taken to an SSO from just about anything, so how am I supposed to know if the entry point from page X is legit compared to the entry point from page Y?

- a corollary to requiring multiple authentications even from the same device (looking at you Microsoft...) is it creates uncertainty as to when I should expect to have to sign in; if opening a link to a report requires me to authenticate or just accessing an internal web portal requires additional auth, why should I be suspicious when my colleague's account gets compromised and an attacker sends me a link saying "hey, we need to respond on this form by EOD; don't have time to explain in full, but it's pretty straight-forward. I'll follow up in a few hours when I'm done with another item"

- Edited: another corollary with SSO means that getting auth'd once means you get auth'd a lot. While you should need to configure additional security and checks on more sensitive services, since you're already auth'd through the main means of identification, it's often trivial to get the access by normal means or to social engineer access

It really sucks to be an end user in such environments, and it's just too easy for IT security to absolutely lock out legitimate users who are following the policies as best they can with earnest intent.