Blocking the creation of generic users

In several occasions, such as allowing facilitated access by a supplier, users considered "generic" are created in the system, which have a default name or one that is easy to guess, and that can facilitate ill-intentioned attacks that explore the existence of these users to access the system without authorization.

Therefore, in this version, the system will block the creation of new generic users. That is, the creation of users with logins such as "sesuite" or "softexpert" will be blocked, and other logins that also cannot be used may be identified in the future.

These users are considered generic since they have the name, or part of the name, of the company (SoftExpert) or the product (SE Suite) in the login, which makes them easy to guess.

To ensure that these users are no longer used, in the next version, the users considered generic that already exist in the system will be automatically disabled during the update process, and it will no longer be possible to enable them.

Therefore, we request you to revise the records of these users, and the integrations that use them must be edited not to need them anymore, avoiding negative impacts in the routine of the organization once these users are disabled in the next version update.

 

Minimum configuration for password strength

It has been identified that, in some cases, the password strength was not configured strong enough for system users, allowing the use of passwords such as "123456", "test" and others, increasing the risk of ill-intentioned attacks accessing the system without authorization.

This problem would increase when combined with "generic" users, since the attacker could test simple combinations of users and passwords and access the system even with a MANAGER profile.

So, also for security reasons, from now on the product demands the use of a minimum password strength configuration, in which it must have at least 6 characters and be composed of letters and numbers.

Due to this change, if your system does not have at least this password strength configuration, it will be automatically updated to respect this new minimum configuration, and it will require all users to update their passwords.

Therefore, it is important for this password strength configuration to be revised in your system and, if necessary, for users to be notified, so that the security concerns, the reason why the new password is required, are shared with everyone.

 

Countersign update

For security reasons, the user countersign now must always respect the password strength configuration set in the system, as avoiding weak countersigns is just as important as avoiding weak passwords.

Therefore, the users who already have a countersign created must update them to continue working on the system countersign verifications/confirmations, as well as on activity execution (if the system is configured as such).

 

 

Leader synchronization configuration

Previously, some leader synchronization parameters were quite complex to define, as they were confused with the user parameters for the proximity of their fields on the screen. Moreover, the customization of the leader ID # field could be configured only through the ADPARAMS table, which turned it into a "hidden" configuration (hard to visualize).

Therefore, this version displays an improvement on the screen to highlight the leader synchronization configuration, and a field was added to allow customizing the leader ID # field, removing the need to use the ADPARAMS table to do so.

 

 

Configuration of monthly schedulings executed on the final day of the month

When a scheduling with a monthly frequency was configured for the 30th and 31st of each month, it would not be executed in February, as this month ends on the 28th (or 29th in leap years).

So, to prevent a scheduling not to be executed in February, from now on, the system will always consider the scheduling to be executed on the last day of the month if the frequency is monthly and the chosen day is later than or equal to the 28th.

 

 

Removal of the customized URL feature in e-mails

When the system URL sent in the e-mails was customized, it changed only the e-mail link, but never the original system URL, which it never aimed to change.

Thus, several users could not access the application due to the mismatched addresses, since no network policies were edited, only the e-mail link.

A quite recurring example was the fact that users outside of the company network could access the system through the e-mail link, and users within the network could not, or vice-versa.

Therefore, the feature has been discontinued in order to avoid these mishaps, leaving the access rules of this type, such as allowing the access to the application through another address, to be performed at the network level, such as DNS and Firewall rules, among other tools that are already specialized in this purpose, instead of the SE Suite application.

 

Removal of the feature to export to Excel from the SQL editor

This feature has been removed from the SQL editor screen, as there already is a much more advanced feature in the system to perform analyses in the application database and even in other data sources. Moreover, this screen only works to perform superficial analyses, to test SQL commands and other simple operations.

If you need to perform more advanced analyses or publish them in portals, for example, use the SE Analytics component.

 

Previous versions

View also the improvements made to this component in previous versions: