Session management

BSI IT-Grundschutz 2023 sections covered by this page

• CON.10
• APP.3.1

A complete description of login mechanisms can be found at https://oxpedia.org/wiki/index.php?title=Login_variations.

Feature Description

In a basic scenario the user logs in with his credentials that are securely transferred to the OX App Suite middleware via HTTPS and are authenticated there by one of the available internal mechanisms. At most environments however, authentication is performed by integrating with an external trustworthy identity management (IDM) solution already existing in the environment. OX App Suite manages the users' session, regardless if internal or external authentication is used.

When using external authentication sources, like Single Sign-On (SSO) systems, user credentials are not stored at the OX App Suite database. While the database schema always contains a field to store a password, it might not be used in such cases.

After successful authentication a time-stamped session is created along with unique identifiers for that session for user-bound lookup. The identifiers generated are universally unique identifiers (UUID). As long as the session is frequently accessed, it stays active, unless the user explicitly performs a logout. With increasing idle time the session is moved more and more towards a long-term session container. When stored in such a long-term container, the session loses all bound resources, which are restored if that session is accessed again. If still idling in long-term container, the session is finally removed orderly. Both short-term and long-term idle time is configurable.

Any session related operations is logged at the default log level by default and should be considered for monitoring to identify attacks.

Potential Security Risk

Attacking the session management process can lead to session takeover, which enables attackers to impersonate other accounts and perform illegitimate actions on their behalf.

Current Implementation and Completeness

The needed identifiers to access sessions are divided into two parts: session identifier and secret identifier. Both are unique throughout the whole cluster. The session identifier is used to look up an associated session whereas the secret identifier is considered as the session’s companion identifier to ensure that the session is accessed in an authorized way. Thus, only if both identifier match, access to the session is granted.

There are two ways of transporting these identifiers between the server and the browser: in private (optional) and public mode. "Public mode" means, the user selects "I’m working on a publically available device", e.g. in an internet café, therefore not all session related data will be stored within the browser, e.g. as cookie. This affects the possible level of comfort for the user; as for example closing the browser window also terminates the session.

Therefore, the "private mode" is available as well, where the user selects "I’m working on a secure private device". That option is labeled as "Stay signed in" in the OX App Suite user interface. In this case, the session lifetime can be longer, session identifiers will be stored persistently in the browser to allow a flawless re-login, if for example the browser’s window was closed.

In public mode the session identifier is given as a URL parameter, whereas a special cookie provides the secret. That cookie’s name is further bound to the operating user’s client through appending a calculated hash string derived from configurable client parts (client ID, user-agent, etc.).

In private mode, a special cookie also provides the session identifier with same calculated hash string appended to its name. The hash strings are compared to the calculated hash string from the information of current client.

Beside that identifier-based lookup, the OX App Suite middleware also provides an optional IP address filter. Meaning, if a session’s client tries to access with a changed IP address, the session is no more accessible. This function is activated in default configuration. There is an additional mechanism for retrieving non-sensitive information e.g. images through a new cookie that can be used instead of normal session identifier. This allows the usage of static URLs to better utilize the existing browser cache. This is an optional feature.

Login Variations

OX App Suite provides a few different login mechanisms to generate a secure session for the end-user. Each of these have security measures of their own to ensure the safety of the users data and privacy. The OX App Suite middleware includes a session daemon (sessiond) that keeps the current data of a logged-in user. If successfully authenticated, the information kept in the session is sufficient for accessing OX App Suite middleware. Login variations are described in detail at https://oxpedia.org/wiki/index.php?title=Login_variations and https://documentation.open-xchange.com/8/middleware/login_and_sessions/session_security_features.html.

Multifactor authentication

OX App Suite offers an implementation to include multifactor authentication ("MFA") during the login process. A number of popular protocols such as TOTP, U2F and SMS are supported and can be managed by the user. If enabled, the application requests a token through a second factor after the primary authentication step has been successfully completed. Users can add, remove and rename MFA devices or endpoints as well as defining a recovery device in case the default MFA device has been lost.

Operators can view and remove MFA devices specified by the user, for example to perfom a reset. There are multiple configuration parameters for this authentication step, including a way to reject MFA for a specified amount of time if a specified amount of incorrect MFA tokens were provided. Note that in order to deliver the authentication token, third-party services might be used such as SMS gateways. Those need to be considered when evaluating the risk and attack surface in terms of confidentiality and availability.

Since the mechanism is integrated to the authentication workflow, it can be combined with other login variations like Form- or Token-Login. The mechanism has been part of a dedicated code-review and dynamic penetration test.

When using external authentication sources, it is advised to also use MDA capabilities of those sources to avoid keeping authentication data at various places.