That can be done by disabling the configuration "SessionCheckRemoteIP", enabling "SessionUseCookieAfterBrowserClose", and setting "SessionMaxTime" & "SessionMaxIdleTime" to "2592000".
I'd still suggest a "Keep me logged in/Stay signed in" button, which, depending on the check, makes the cookie a session cookie "SessionUseCookieAfterBrowserClose".

Best regards
Emin

I am against this suggestion, our OTRS system contains sensitive to highly sensitive information on users. OTRS also hosts some Oversighters queues by the way.

Changing this setting as suggested would decrease security. I will add the security-team project in the loop.

This might be something worth looking at after 2fa becomes unbroken and available. (T122220)

In T231954#5464019, @Scoopfinder wrote:

I am against this suggestion, our OTRS system contains sensitive to highly sensitive information on users. OTRS also hosts some Oversighters queues by the way.

Changing this setting as suggested would decrease security. I will add the security-team project in the loop.

I appreciate this concern, but the various functionary-only wikis all allow me to remain logged in for one year. Phabricator seems to let me stay logged in for five years(!). I wouldn't suggest going that far here, but I get the impression that the current settings for OTRS are more a matter of software defaults than a reasoned decision about the best balance between usability and security. (I didn't find much in the way of past discussions about this, but I'd be happy to look at any that are unearthed.)

Concerning security, I note that a few years ago it was noticed that an agent could inadvertedly share a URL with other agents or third parties that would allow the latter to take over their OTRS session. This could happen because: (1) While SessionUseCookie was set to true (default setting), when OTRS was unable to access the agent's cookies, it added the session ID to the URL (apparently the default behaviour). (2) SessionCheckRemoteIP was set to false in our OTRS instance because agents with highy dynamic/IPv6 IPs had issues accessing OTRS (T87217). The combination of (1) and (2) enabled the recipients of the URL to hijack the agent's session. (Furthermore, several now-fixed bugs were discovered in the past where a session ID was appended to a URL in certain circumstances even though the agent's cookies were working fine. T210861 perhaps being the latest example.) If the aforesaid still reflects the current behaviour of OTRS/Wikimedia's OTRS instance, I would submit that this cuts against a high SessionMaxTime/SessionMaxIdleTime from a risk mitigation point of view.

Generally speaking, it appears to me that OTRS is not really designed for the use with very long sessions, so I could imagine some other issues to arise. Just off the top of my head, for instance, my understanding is that the Online Agent dashboard widget is effectively a list of agents with active, non-idle sessions, so if you increase the SessionMaxIdleTime to a month, the widget would become rather useless. Also, under the default settings, the amount of sessions is limited, which is something that should probably be taken into account before significantly extending the time before a session is killed.

As a side note, during my 12-or-so years on the email response team and during my time as an OTRS admin, I have never heard of a "collective frustration" with "re-logging-in numerous times each week". Rather, what was brought to our attention numerous times was a frustration with sessions being killed while composing a reply and then losing the unfinished reply (see eg T198824). This has led to calls for a slightly prolonged SessionMaxIdleTime (which I think was implemented[?]; the default is just 2h) as well as an autosave feature to restore unfinished responses (which, alas, OTRS still does not provide out of the box).

Very good specific points, thank you for that information. With that in mind, and especially the missing 2FA, I suppose this proposal might be declinable.

For context, I don't allow my browser to store any passwords, so logging-in once a day (or more) is a slightly cumbersome process (via password manager). It breaks my mental flow, and reduces the likelihood that I (and I imagine others) will check the site. This is also the only site I have to do this process in so frequently; however I do have 2FA at all other significant accounts.

For background, I have heard a few people grumble about it over the years in casual chat. However that annoyance-factor does not override the security concerns described in detail above by pajz. Thanks again for those details.

I won't self-decline the task yet, just in case there are additional points or newer settings that someone knows about which could make this more feasible.

I will say that OTRS session timeouts are much less annoying than ACC session timeouts because OTRS will return you to where you left off (assuming that you weren't writing something, of course).

Concerning security, I note that a few years ago it was noticed that an agent could inadvertedly share a URL with other agents or third parties that would allow the latter to take over their OTRS session

As you point out it was possible barely a couple of months ago (T210861).

Some more information:

• The default session length is currently 16 hours, with a 2h max idle window before a logout is forced. Intuitively (I don't have numbers so feel free to contradict me), I 'd expect the grievance mentioned in this task to be with the latter and not the former. If I am right, perhaps we can partially alleviate this, while also addressing the security concerns mentioned above by lowering the default session length, thereby giving less time to a possible attacker to wreck havoc, while also increasing the max idle timeout to allow for agents to be away from their sessions for >2 hours before having to relogin.

• Furthermore, the session cookie is specifically configured to not persist across session (and it is fully orthogonal to the timeouts mentioned above). This does not work as one would expect (e.g. stopping the application) with chromium based browsers, for a long time now (since 2012) due to a redefinition on that team's part on what a session is[1]. Browsers not based on chromium (e.g. firefox) do not exhibit this behavior. While this behavior on the part of chromium based browsers diminishes the setting's usefulness, changing it would constitute altering the behavior for a number of agents who don't use those browsers (I don't have numbers, sorry) that have possibly grown accustomed to it and thus potentially adversely affecting the security of the system.

• Note that this is orthogonal to 2 factor authentication. Even if we enabled 2FA (which we should at some point), it would not protect against session high jacking.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=130291

Upon review, Security Team is untagging as we will not be working on this ticket.

Any action on this? Normally this wouldn't bug me, but having to put in a 2FA token EVERY time is almost convincing me to deactivate 2FA because entering it multiple times a day is a bit ridiculous. Without 2FA I just have my password auto-filled by my password manager so it's no big deal - but this "security" feature is really having the opposite effect.

Given T275294, I have my doubts anyone will be investing time in this, especially since that investment might go down the drain sooner rather than later.