User Session Management - Revision history

Ollvihe: /* Preventing password guessing attacks */

2023-10-19T13:23:55Z

Preventing password guessing attacks

← Older revision		Revision as of 13:23, 19 October 2023
Line 19:		Line 19:

	== Preventing password guessing attacks ==		== Preventing password guessing attacks ==
	QPR ProcessAnalyzer has a mechanism to prevent brute-force password guessing attacks. Each failed login attempt is recorded, and if there has been total of five (5) failed login attempts to a specific account, that account is locked for five (5) minutes. During the lockout period, all login attempts are rejected. After the lockout period, the account is again available for logins. In a longer time period, this mechanism allows ~~to make~~ on average maximum of one password guess attempt per minute. If using strong passwords (at least 8 characters long), the probability of a successful guess in an attack that lasts for examples weeks, is ~~very~~ low. Note that the lockout is account specific, so it's possible to perform the attack for each user account separately.		QPR ProcessAnalyzer has a mechanism to prevent brute-force password guessing attacks. Each failed login attempt is recorded, and if there has been total of five (5) failed login attempts to a specific account, that account is locked for five (5) minutes. During the lockout period, all login attempts are rejected. After the lockout period, the account is again available for logins. In a longer time period, this mechanism only allows on average maximum of one password guess attempt per minute. If using strong passwords (at least 8 characters long), the probability of a successful guess in an attack that lasts for examples weeks, is extremely low. Note that the lockout is account specific, so it's possible to perform the attack for each user account separately.

	The failed login attempts are logged ([[QPR_ProcessAnalyzer_Logs#Server_Log\|more information]]), and it's recommended for the system administrator to monitor the logs regularly, to detect possible password guessing attacks that are in progress. In case there is an attack, it's recommended to ask users to change their passwords and make sure that strong passwords are used. In addition, if the attack comes from specific IP addresses, it may be possible to block those IP addresses, to prevent the attack from continuing. In addition, for maximum security it's recommended to use external identity provider through the SAML 2.0 protocol, because in that case authentication using the QPR ProcessAnalyzer password is not possible and thus the password guessing attacks are not possible either.		The failed login attempts are logged ([[QPR_ProcessAnalyzer_Logs#Server_Log\|more information]]), and it's recommended for the system administrator to monitor the logs regularly (i.e., perform SIEM, Security Information and Event Management), to detect possible password guessing attacks that are in progress. In case there is an attack, it's recommended to ask users to change their passwords and make sure that strong passwords are used. In addition, if the attack comes from specific IP addresses, it may be possible to block those IP addresses, to prevent the attack from continuing. In addition, for maximum security it's recommended to use external identity provider through the SAML 2.0 protocol, because in that case authentication using the QPR ProcessAnalyzer password is not possible and thus the password guessing attacks are not possible either.

Ollvihe: /* User authentication and sessions */

2022-02-15T15:51:47Z

User authentication and sessions

← Older revision		Revision as of 15:51, 15 February 2022
Line 2:		Line 2:

	== User authentication and sessions ==		== User authentication and sessions ==
	All requests to QPR ProcessAnalyzer are performed by a user account. Users needs to authenticate first to start a new session. Authentication can be performed by a password stored to QPR ProcessAnalyzer, or an external identity provider through SAML 2.0 protocol can be used. As a result of the successful authentication, the user gets a session token, that is stored in the user's web browser. Once the user is authenticated, all subsequent requests authenticate using the session token, which is included into each request as HTTP request header. The session token in the request is then validated in QPR ProcessAnalyzer Server. If the session token is not valid, the request is rejected.		All requests to QPR ProcessAnalyzer are performed by a user account. Users needs to authenticate first to start a new session. Authentication can be performed by a password stored to QPR ProcessAnalyzer, or an external identity provider through [[SAML_2.0_Federated_Authentication\|SAML 2.0 protocol]] can be used. As a result of the successful authentication, the user gets a session token, that is stored in the user's web browser. Once the user is authenticated, all subsequent requests authenticate using the session token, which is included into each request as HTTP request header. The session token in the request is then validated in QPR ProcessAnalyzer Server. If the session token is not valid, the request is rejected.

	The session token is identified by GUID (global unique identifier). The length of the GUID (128 bits) guarantees uniqueness across space and time. New GUIDs are created by using the NEWID() function provided by SQL Server (https://docs.microsoft.com/en-us/sql/t-sql/functions/newid-transact-sql?view=sql-server-2017). The generated GUID's are compliant with RFC 4122 (https://tools.ietf.org/html/rfc4122).		The session token is identified by GUID (global unique identifier). The length of the GUID (128 bits) guarantees uniqueness across space and time. New GUIDs are created by using the NEWID() function provided by SQL Server (https://docs.microsoft.com/en-us/sql/t-sql/functions/newid-transact-sql?view=sql-server-2017). The generated GUID's are compliant with RFC 4122 (https://tools.ietf.org/html/rfc4122).

Ollvihe: /* Log off and session expiration */

2022-02-15T15:50:01Z

Log off and session expiration

← Older revision		Revision as of 15:50, 15 February 2022
Line 16:		Line 16:
	* '''Session idle timeout''': If the user session has not been used (i.e. there are no requests sent to the server), the session is invalidated after this duration. The purpose is to get the session invalidated soon, e.g. if user has not log out the session after usage. By default this time is one hour.		* '''Session idle timeout''': If the user session has not been used (i.e. there are no requests sent to the server), the session is invalidated after this duration. The purpose is to get the session invalidated soon, e.g. if user has not log out the session after usage. By default this time is one hour.
	* '''Session maximum duration''': Duration starting from the login after which the session is invalidated anyways (even though it is used continuously). The purpose is to get the session invalidated e.g. in cases where some automated script maintains the user session for ever. The best practice for these kind of scripts is to logout the session after the communication has been completed. The session maximum duration is by default 24 hours.		* '''Session maximum duration''': Duration starting from the login after which the session is invalidated anyways (even though it is used continuously). The purpose is to get the session invalidated e.g. in cases where some automated script maintains the user session for ever. The best practice for these kind of scripts is to logout the session after the communication has been completed. The session maximum duration is by default 24 hours.
	When there is a script running, the user session ~~where the script is running,~~ is kept alive for the duration of the script run. The session maximum duration is still applied, so it's not possible to run scripts longer than the defined session maximum duration.		When there is a script running, the related user session is kept alive for the duration of the script run. The session maximum duration is still applied, so it's not possible to run scripts longer than the defined session maximum duration.

	== Preventing password guessing attacks ==		== Preventing password guessing attacks ==

Ollvihe at 15:49, 15 February 2022

2022-02-15T15:49:36Z

← Older revision		Revision as of 15:49, 15 February 2022
Line 2:		Line 2:

	== User authentication and sessions ==		== User authentication and sessions ==
	All requests ~~done~~ to QPR ProcessAnalyzer are performed by a user account. ~~First, the user~~ needs to authenticate to start a new session. Authentication can be performed by a password stored to QPR ProcessAnalyzer, or an external identity provider through SAML 2.0 protocol can be used. As a result of the successful authentication, the user ~~will get~~ a session token, that ~~needs~~ is stored in the user's web browser. Once the user is authenticated, all subsequent requests authenticate using the session token, which is included into each request as HTTP request header. The session token in the request is then validated in QPR ProcessAnalyzer Server. If the session token is not valid, the request is rejected.		All requests to QPR ProcessAnalyzer are performed by a user account. Users needs to authenticate first to start a new session. Authentication can be performed by a password stored to QPR ProcessAnalyzer, or an external identity provider through SAML 2.0 protocol can be used. As a result of the successful authentication, the user gets a session token, that is stored in the user's web browser. Once the user is authenticated, all subsequent requests authenticate using the session token, which is included into each request as HTTP request header. The session token in the request is then validated in QPR ProcessAnalyzer Server. If the session token is not valid, the request is rejected.

	The session token is ~~a 128-bit number called Global Unique IDentifier~~ (~~GUID~~). The length of the GUID (128 bits) ~~can guarantee~~ uniqueness across space and time. New GUIDs are created by using the NEWID() function provided by SQL Server (https://docs.microsoft.com/en-us/sql/t-sql/functions/newid-transact-sql?view=sql-server-2017). The generated GUID is compliant with RFC 4122 (https://tools.ietf.org/html/rfc4122).		The session token is identified by GUID (global unique identifier). The length of the GUID (128 bits) guarantees uniqueness across space and time. New GUIDs are created by using the NEWID() function provided by SQL Server (https://docs.microsoft.com/en-us/sql/t-sql/functions/newid-transact-sql?view=sql-server-2017). The generated GUID's are compliant with RFC 4122 (https://tools.ietf.org/html/rfc4122).

	For the session management to work in a secure way, the communication channel between the user and the server needs to be secure in terms in confidentiality and integrity. Thus the server needs to be configured to use the HTTPS protocol, with only secure ciphers allowed (more information in the [[QPR_ProcessAnalyzer_Security_Hardening\|security hardening instructions]]).		For the session management to work in a secure way, the communication channel between the user and the server needs to be secure in terms in confidentiality and integrity. Thus the server needs to be configured to use the HTTPS protocol, with only secure ciphers allowed (more information in the [[QPR_ProcessAnalyzer_Security_Hardening\|security hardening instructions]]).
Line 13:		Line 13:

	== Log off and session expiration ==		== Log off and session expiration ==
	When user logs offs a session, its session token is marked as invalid in the sessions table in QPR ProcessAnalyzer database, and thus the session cannot be used anymore. There are ~~the~~ following settings related to session management ([[PA_Configuration_database_table\|more information]]):		When user logs offs a session, its session token is immediately marked as invalid in the sessions table in QPR ProcessAnalyzer database, and thus the session cannot be used anymore. There are following settings related to session management ([[PA_Configuration_database_table\|more information]]):
	* '''Session idle timeout''': If the user session has not been used (i.e. there are no requests sent to the server), the session is invalidated after this duration. The purpose is to get the session invalidated soon, e.g. if user has ~~forgotten to~~ log out the session. By default this time is one hour.		* '''Session idle timeout''': If the user session has not been used (i.e. there are no requests sent to the server), the session is invalidated after this duration. The purpose is to get the session invalidated soon, e.g. if user has not log out the session after usage. By default this time is one hour.
	* '''Session maximum duration''': Duration starting from the login after which the session is invalidated anyways (even though it is used continuously). The purpose is to get the session invalidated e.g. in cases where some automated script maintains the user session for ever. The best practice for these kind of scripts is to logout the session after the communication has been completed. The session maximum duration is by default 24 hours.		* '''Session maximum duration''': Duration starting from the login after which the session is invalidated anyways (even though it is used continuously). The purpose is to get the session invalidated e.g. in cases where some automated script maintains the user session for ever. The best practice for these kind of scripts is to logout the session after the communication has been completed. The session maximum duration is by default 24 hours.
			When there is a script running, the user session where the script is running, is kept alive for the duration of the script run. The session maximum duration is still applied, so it's not possible to run scripts longer than the defined session maximum duration.

	== Preventing password guessing attacks ==		== Preventing password guessing attacks ==

Ollvihe at 19:36, 11 December 2021

2021-12-11T19:36:26Z

← Older revision		Revision as of 19:36, 11 December 2021
Line 13:		Line 13:

	== Log off and session expiration ==		== Log off and session expiration ==
	When user logs offs a session, its session token is marked as invalid in the sessions table in QPR ProcessAnalyzer database, and thus the session cannot be used anymore. There are the following settings related to session management ([[~~PA_Configuration_database_table_in_QPR_ProcessAnalyzer~~\|more information]]):		When user logs offs a session, its session token is marked as invalid in the sessions table in QPR ProcessAnalyzer database, and thus the session cannot be used anymore. There are the following settings related to session management ([[PA_Configuration_database_table\|more information]]):
	* '''Session idle timeout''': If the user session has not been used (i.e. there are no requests sent to the server), the session is invalidated after this duration. The purpose is to get the session invalidated soon, e.g. if user has forgotten to log out the session. By default this time is one hour.		* '''Session idle timeout''': If the user session has not been used (i.e. there are no requests sent to the server), the session is invalidated after this duration. The purpose is to get the session invalidated soon, e.g. if user has forgotten to log out the session. By default this time is one hour.
	* '''Session maximum duration''': Duration starting from the login after which the session is invalidated anyways (even though it is used continuously). The purpose is to get the session invalidated e.g. in cases where some automated script maintains the user session for ever. The best practice for these kind of scripts is to logout the session after the communication has been completed. The session maximum duration is by default 24 hours.		* '''Session maximum duration''': Duration starting from the login after which the session is invalidated anyways (even though it is used continuously). The purpose is to get the session invalidated e.g. in cases where some automated script maintains the user session for ever. The best practice for these kind of scripts is to logout the session after the communication has been completed. The session maximum duration is by default 24 hours.

Ollvihe: /* Preventing password guessing attacks */

2021-10-20T14:11:33Z

Preventing password guessing attacks

← Older revision		Revision as of 14:11, 20 October 2021
Line 20:		Line 20:
	QPR ProcessAnalyzer has a mechanism to prevent brute-force password guessing attacks. Each failed login attempt is recorded, and if there has been total of five (5) failed login attempts to a specific account, that account is locked for five (5) minutes. During the lockout period, all login attempts are rejected. After the lockout period, the account is again available for logins. In a longer time period, this mechanism allows to make on average maximum of one password guess attempt per minute. If using strong passwords (at least 8 characters long), the probability of a successful guess in an attack that lasts for examples weeks, is very low. Note that the lockout is account specific, so it's possible to perform the attack for each user account separately.		QPR ProcessAnalyzer has a mechanism to prevent brute-force password guessing attacks. Each failed login attempt is recorded, and if there has been total of five (5) failed login attempts to a specific account, that account is locked for five (5) minutes. During the lockout period, all login attempts are rejected. After the lockout period, the account is again available for logins. In a longer time period, this mechanism allows to make on average maximum of one password guess attempt per minute. If using strong passwords (at least 8 characters long), the probability of a successful guess in an attack that lasts for examples weeks, is very low. Note that the lockout is account specific, so it's possible to perform the attack for each user account separately.

	The failed login attempts are logged ([[QPR_ProcessAnalyzer_Logs#Server_Log\|more information]]), and it's recommended for the system administrator to monitor the logs regularly, to detect possible password guessing attacks that ~~have been~~ in progress. In case there is an attack ~~in progress~~, it's recommended to ask users to change their passwords and make sure that strong passwords are used. In addition, if the attack comes from specific IP addresses, it may be possible to block those IP addresses, to prevent the attack from continuing. It's ~~also~~ recommended to use external identity provider through the SAML 2.0 protocol, because in that case authentication using the QPR ProcessAnalyzer password is not possible and thus the password guessing attacks are not possible either.		The failed login attempts are logged ([[QPR_ProcessAnalyzer_Logs#Server_Log\|more information]]), and it's recommended for the system administrator to monitor the logs regularly, to detect possible password guessing attacks that are in progress. In case there is an attack, it's recommended to ask users to change their passwords and make sure that strong passwords are used. In addition, if the attack comes from specific IP addresses, it may be possible to block those IP addresses, to prevent the attack from continuing. In addition, for maximum security it's recommended to use external identity provider through the SAML 2.0 protocol, because in that case authentication using the QPR ProcessAnalyzer password is not possible and thus the password guessing attacks are not possible either.

Ollvihe at 11:38, 20 October 2021

2021-10-20T11:38:48Z

← Older revision		Revision as of 11:38, 20 October 2021
Line 20:		Line 20:
	QPR ProcessAnalyzer has a mechanism to prevent brute-force password guessing attacks. Each failed login attempt is recorded, and if there has been total of five (5) failed login attempts to a specific account, that account is locked for five (5) minutes. During the lockout period, all login attempts are rejected. After the lockout period, the account is again available for logins. In a longer time period, this mechanism allows to make on average maximum of one password guess attempt per minute. If using strong passwords (at least 8 characters long), the probability of a successful guess in an attack that lasts for examples weeks, is very low. Note that the lockout is account specific, so it's possible to perform the attack for each user account separately.		QPR ProcessAnalyzer has a mechanism to prevent brute-force password guessing attacks. Each failed login attempt is recorded, and if there has been total of five (5) failed login attempts to a specific account, that account is locked for five (5) minutes. During the lockout period, all login attempts are rejected. After the lockout period, the account is again available for logins. In a longer time period, this mechanism allows to make on average maximum of one password guess attempt per minute. If using strong passwords (at least 8 characters long), the probability of a successful guess in an attack that lasts for examples weeks, is very low. Note that the lockout is account specific, so it's possible to perform the attack for each user account separately.

	The failed login attempts are logged ([[QPR_ProcessAnalyzer_Logs#Server_Log\|more information]]), and it's recommended for the system administrator to monitor the logs regularly, to detect possible password guessing attacks that have been in progress. In case there is an attack in progress, it's recommended to ask users to change their passwords and make sure that strong passwords are used. In addition, if the attack comes from specific IP addresses, it may be possible to block those IP addresses, to prevent the attack from continuing. It's also recommended to to use external identity provider through the SAML 2.0 protocol, because in that case authentication using the QPR ProcessAnalyzer password is not possible and thus the password guessing attacks are not possible either.		The failed login attempts are logged ([[QPR_ProcessAnalyzer_Logs#Server_Log\|more information]]), and it's recommended for the system administrator to monitor the logs regularly, to detect possible password guessing attacks that have been in progress. In case there is an attack in progress, it's recommended to ask users to change their passwords and make sure that strong passwords are used. In addition, if the attack comes from specific IP addresses, it may be possible to block those IP addresses, to prevent the attack from continuing. It's also recommended to use external identity provider through the SAML 2.0 protocol, because in that case authentication using the QPR ProcessAnalyzer password is not possible and thus the password guessing attacks are not possible either.

Ollvihe: /* Authentication and session tokens */

2021-09-22T11:36:43Z

Authentication and session tokens

← Older revision		Revision as of 11:36, 22 September 2021
Line 1:		Line 1:
	This page describes how user sessions are managed in QPR ProcessAnalyzer.		This page describes how user sessions are managed in QPR ProcessAnalyzer.

	== ~~Authentication~~ and ~~session tokens~~ ==		== User authentication and sessions ==
	All requests done to QPR ProcessAnalyzer are performed by a user account. First, the user needs to authenticate to start a new session. Authentication can be performed by a password stored to QPR ProcessAnalyzer, or an external identity provider through SAML 2.0 protocol can be used. As a result of the successful authentication, the user will get a session token, that needs is stored in the user's web browser. Once the user is authenticated, all subsequent requests authenticate using the session token, which is included into each request as HTTP request header. The session token in the request is then validated in QPR ProcessAnalyzer Server. If the session token is not valid, the request is rejected.		All requests done to QPR ProcessAnalyzer are performed by a user account. First, the user needs to authenticate to start a new session. Authentication can be performed by a password stored to QPR ProcessAnalyzer, or an external identity provider through SAML 2.0 protocol can be used. As a result of the successful authentication, the user will get a session token, that needs is stored in the user's web browser. Once the user is authenticated, all subsequent requests authenticate using the session token, which is included into each request as HTTP request header. The session token in the request is then validated in QPR ProcessAnalyzer Server. If the session token is not valid, the request is rejected.

Ollvihe: /* Authentication and session tokens */

2021-09-22T11:36:15Z

Authentication and session tokens

← Older revision		Revision as of 11:36, 22 September 2021
Line 9:		Line 9:

	User accounts are stored to the QPR ProcessAnalyzer database and their passwords are stored as one-way hash values calculated with the SHA-256 algorithm. Salt is used in the hashing for protection against the use of rainbow tables.		User accounts are stored to the QPR ProcessAnalyzer database and their passwords are stored as one-way hash values calculated with the SHA-256 algorithm. Salt is used in the hashing for protection against the use of rainbow tables.

	QPR ProcessAnalyzer can load data from external systems, such as SAP or Salesforce.com. When a session is created, credentials are entered by the user and are stored in Windows profile with additional encryption.
	Users loading data from Salesforce.com enter their Salesforce credentials in the Integration Service for Salesforce web UI when launching the transfer. Credentials are not stored on the QPR ProcessAnalyzer.

	[[QPR_ProcessAnalyzer_Logs#Server_Log\|Server log]] keep track of all the usernames that try to authenticate to QPR ProcessAnalyzer. Also, client IP address is logged.		[[QPR_ProcessAnalyzer_Logs#Server_Log\|Server log]] keep track of all the usernames that try to authenticate to QPR ProcessAnalyzer. Also, client IP address is logged.

Ollvihe: /* Preventing password guessing attacks */

2021-09-22T09:02:59Z

Preventing password guessing attacks

← Older revision		Revision as of 09:02, 22 September 2021
Line 23:		Line 23:
	QPR ProcessAnalyzer has a mechanism to prevent brute-force password guessing attacks. Each failed login attempt is recorded, and if there has been total of five (5) failed login attempts to a specific account, that account is locked for five (5) minutes. During the lockout period, all login attempts are rejected. After the lockout period, the account is again available for logins. In a longer time period, this mechanism allows to make on average maximum of one password guess attempt per minute. If using strong passwords (at least 8 characters long), the probability of a successful guess in an attack that lasts for examples weeks, is very low. Note that the lockout is account specific, so it's possible to perform the attack for each user account separately.		QPR ProcessAnalyzer has a mechanism to prevent brute-force password guessing attacks. Each failed login attempt is recorded, and if there has been total of five (5) failed login attempts to a specific account, that account is locked for five (5) minutes. During the lockout period, all login attempts are rejected. After the lockout period, the account is again available for logins. In a longer time period, this mechanism allows to make on average maximum of one password guess attempt per minute. If using strong passwords (at least 8 characters long), the probability of a successful guess in an attack that lasts for examples weeks, is very low. Note that the lockout is account specific, so it's possible to perform the attack for each user account separately.

	The failed login attempts are logged ([[QPR_ProcessAnalyzer_Logs#Server_Log\|more information ~~about logging~~]], and it's recommended for the system administrator to monitor the logs regularly, to detect possible password guessing attacks that have been in progress. In case there is an attack in progress, it's recommended to ask users to change their passwords and make sure that strong passwords are used. In addition, if the attack comes from specific IP addresses, it may be possible to block those IP addresses, to prevent the attack from continuing. It's also recommended to to use external identity provider through the SAML 2.0 protocol, because in that case authentication using the QPR ProcessAnalyzer password is not possible and thus the password guessing attacks are not possible either.		The failed login attempts are logged ([[QPR_ProcessAnalyzer_Logs#Server_Log\|more information]]), and it's recommended for the system administrator to monitor the logs regularly, to detect possible password guessing attacks that have been in progress. In case there is an attack in progress, it's recommended to ask users to change their passwords and make sure that strong passwords are used. In addition, if the attack comes from specific IP addresses, it may be possible to block those IP addresses, to prevent the attack from continuing. It's also recommended to to use external identity provider through the SAML 2.0 protocol, because in that case authentication using the QPR ProcessAnalyzer password is not possible and thus the password guessing attacks are not possible either.