Security Module

Given the inevitable nature and growing trend of security threats and attacks, it is of vital importance that all software has a set of measures to strengthen and prevent security flaws and vulnerabilities, which may put the application and thus the user’s privacy at risk.

Each of the measures and functionalities that make up the extended Security Module for WOCU Monitoring are presented in detail below.

Forced password change

When creating or resetting user accounts, initial passwords are generated that are only valid for the user’s first login. After this, the system forces a password change.

The process is very simple, the user must first enter the initial password provided and then define a new one, imitating a pre-established pattern to comply with the Strict password policy applied. Finally, this new credential must be re-entered as confirmation of the new credential.

If the password meets the requested requirements, the action will be verified and the user will be allowed to access the home interface of the tool, via the Go to Dashboard button.

Attention

If the initial forced password change is not carried out, the associated user account remains disabled. With this measure, the automatic creation of users is possible in a completely secure manner.

Strict password policy

As a measure to reinforce the security and protection of the tool, a strict password policy is employed, consisting of the following control measures:

✓ Each password has a maximum validity of 90 days.

Also, through a user expiration task executed periodically, inactive user accounts that have not logged in for a certain period of time will be identified and blocked (this value is configurable).

Then users who exceed at least one of the marked time restrictions will be disabled in WOCU.

✓ On changing passwords:

• Checking the proposal against a dictionary of undesirable passwords. If there is a match, it will be denied by the system.

• Checking the proposal against a history of passwords to avoid reuse and repetition. If there is a match, it will be denied by the system.

✓ Minimum requirements for password construction:

• The use of more than two identical characters in succession is prohibited.

• The password may not be identical to the username of the account.

• Minimum length of 8 characters.

• Must contain at least 2 of each of the following: upper case, lower case, numbers and special characters (non-alphanumeric).

Passwords must meet and exceed all stipulated complexity requirements, which are considered essential to mitigate any existing security threats.

Resetting passwords

Availability of a separate portal for resetting passwords by the user himself (regardless of his role). This portal will be accessible from the top navigation bar, in the drop-down menu of the user (with which the system has been accessed) will appear the new option Change Password, as shown in the following image:

To proceed with the password reset, it is necessary to insert the old password and twice the new password as a confirmation measure. Remember that it must comply with the stipulated Strict password policy.

Captchas

Insertion of this user verification technology, in order to limit the ability of attackers to enter the interface using automated means.

This resource will remain fixed on the login page of the tool, located after the request for the user’s access credentials. Whenever a new session is started, the user must pass this test. The challenge is to type the obfuscated letters shown in the image.

Note

Although the system uses a basic captcha, the implementation allows the use of Google’s recaptcha.

Blocking of accounts in the event of successive unsuccessful attempts

Ability to monitor interface access attempts and prevent brute force attacks when a previously configured limit of allowed attempts is exceeded. Access attempts shall be monitored by IP address, username, user agent, or a combination of both.

When the limit of successive failed attempts is exceeded, the account will be automatically blocked for at least 20 minutes. Only the platform administrator can enable/disable the blocking of user accounts.

The information from these activities will persist in the database, making it possible to perform audits or forward recorded events to other systems.

Important

The number of failed attempts and the disabling time of the blocked account are fully configurable.

Additionally, having already accessed the tool, new data is included in the following informative views:

• Login Information: this view is only accessible to Administrators and includes the following information:

  • Connected accounts logged in at the same time: showing account IDs, total sessions and last successful login to the application.

  • History of failed attempts: specifying user and timestamps of failed attempts.

• User Login Information: this view is accessible to the user logged in to the application and includes the following information:

  • Identification data of the user account registered in WOCU.

  • History of failed attempts since last successful login.

Re-use of passwords

As indicated in the applied Strict password policy, there is a history of hashes (unique and unrepeatable identifiers) for checking during password change.

This is a preventive measure against the reuse and repetition of passwords previously used in an account. Therefore, if there is a match between any element of the history and the proposed password, this will be rejected by the system.

Note

The number of passwords per user that are saved in the history is configurable. The system sets 12 by default.

Control of sessions

The Security Module does not allow the reuse of session tokens, as an impediment to session filtering. In contrast, WOCU acts as follows:

✓ The IP address and browser signature is recorded for each login to the platform.

✓ It is checked that the session token used by a user belongs to the same registered IP address and browser signature.

✓ If an attacker uses the same session token using another IP address or web browser, the session is automatically invalidated for that attacker.

These checks ensure that if a user’s session is obtained, for example, by a man-in-the-middle attack on an unencrypted connection, it cannot be reused from a different IP address or from a different User-Agent. If it is reused, the compromised session in question is immediately invalidated.

Second authentication factor

Finally, this module includes the possibility of integrating two-factor authentication mechanisms, after installing the Google Authenticator application or an analogous one that supports the TOTP protocol. Basically, this security mechanism allows to set an additional challenge to the password and the Captchas during login.

The configuration of this functionality will be carried out from a new independent portal called Two Factor Authentication, accessible from the top navigation bar, in the user’s drop-down menu (with which the system has been accessed), as shown in the following image:

Once inside the configuration portal, the functionality will be enabled by using the Enable Two-Factor Authentication option.

In the next view, we will have to confirm again the enabling of this mechanism by clicking on the Next button. You can revoke the action by going back to the previous view with the Back button or cancel the process by clicking Cancel.

You will then be taken to a new window where you will have to scan (with the Google Authenticator application or an analogous application that supports the TOTP protocol) the QR code shown.

Once scanned, the application will automatically return a code that the user must enter in the Token field.

Once the action has been validated, the second factor will be enabled correctly for the user in question.

Although not strictly necessary, it is recommended that users save single-use tokens, which they can enter in case they have lost access to their mobile host. To do so, with the second authentication factor enabled, within the Account Security view in the Backup Tokens section, select the Show Codes option to access the complete list of single-use tokens, useful as a backup method.

Attention

Remember to copy the code to a safe place for future use.

Once the configuration is complete, once the user logs back into the tool and enters their login credentials and passes the Captchas, they must enter the token generated on their mobile host or the single-use backup token.

Finally, from the Account Security view, section Disable Two-Factor Authentication, it is possible to disable this security mechanism. To do so, check the box Yes, I am sure and confirm the action by clicking on the Disable button.

Restricting the indexing of exposed portals

This is a measure to block the crawling and indexing of portals accessing the application by search engines.

In other words, with the implementation of this enforcement function, the various instances of WOCU-Monitoring that are being exposed to the internet and consequently served as search results are prevented from being located and accessed.

Limitations of the Security Module

Currently, the Security Module does not include support for delegated authentication such as LDAP or Active Directory. Therefore, such a module cannot be used in conjunction with the delegated authentication module also provided by WOCU.

Additional module and how to contract it

The Security Module is not distributed by default in WOCU-Monitoring, it is included in the Platinium version.

It is intended for customers with specific security needs. If this is your case, contact our Commercial Team and they will solve all your doubts.