Password Security Policies

To improve security, user passwords can no longer be saved as plaintext or with an asterisk (*) in the database. The asterisk is now resolved to its actual encoding algorithm so the proper encoding key is saved instead.

Plaintext encoding is no longer allowed. The system now automatically applies the default encoding algorithm to any password that would have previously been stored in plaintext. Dedicated checks have been implemented to detect plain encoding attempts. When such an attempt is discovered, the system seamlessly intervenes by applying the default encoding algorithm to the password. It also replaces any reference to "plain" encoding with the name of the default algorithm used.

The implementation of the asterisk (*) encoding symbol has changed. Previously, it served as a configurable placeholder for various encoding algorithms, allowing system administrators to modify the mapping. This flexibility came with potential risks, as altering the algorithm associated with the asterisk could inadvertently disrupt user login processes for existing accounts.

To address these concerns, the system now maps the asterisk encoding to a specific default encoding in the background. This approach resolves the actual encoding while maintaining compatibility with existing user data. Instead of storing the asterisk symbol itself, the system now saves the name of the algorithm being used. The use of the asterisk for encoding new passwords has been discontinued.

Additionally, the UserPasswordTranslator class has been updated to follow the same configuration settings for password hashing as other parts of the system.

Passwords set through ImpEx are now audited for validity in all cases for both user creation and password updates. Therefore, the new configuration, which prevents passwords from being saved with asterisks, cannot be bypassed when using ImpEx to import new users or data. The system now consistently saves passwords according to the set password encoding, regardless of the method used (Backoffice or ImpEx).

Empower Backoffice users to change their expired password without contacting system administrators.

Internal users can now change their expired passwords by entering their old credentials:

This feature is activated by default and is used for both initial and expired passwords. Users with initial passwords are prompted to change their passwords on their first sign-in.

As part of this feature, a grace period has been introduced to give users additional time to change their password. For example, the password validity period is 10 days and the grace period is 15 days, which means that users are granted a total of 25 days, 10-day validity period plus a 15-day grace period, to update their password. When the password expires after the 10-day validity period, the grace period begins. During the grace period, users are prompted to change their password, but they can still sign in by choosing the Back to Sign In option.

After the password expiration period has passed, user accounts are locked. Once the grace period has elapsed, the user accounts become disabled. At this point, users can no longer change their passwords themselves and must contact the system administrators for assistance.

You can set the value of the grace period in Backoffice in User Groups > Administration > Expired password grace period in days or through the platform.authentication.expired.password.grace.period.fallback.days property. The default value of this property is 36135 days (99 years), which effectively gives users almost indefinite time to change their password.

The grace period isn't applied to initial passwords.

To improve security, you can now activate password quality checks to ensure that user passwords meet quality requirements.

You can now activate password quality checks to ensure that user passwords meet specific quality requirements. The requirements are as follows:

• Passwords must be between 8 and 255 characters in length.
• Passwords must include at least one digit.
• Passwords must contain at least one lowercase letter.
• Passwords must have at least one uppercase letter.
• Passwords must feature at least one special character.

Passwords quality checks are deactivated in the default configuration. To activate them, change the value of the password.policy.fallback.enabled property to true.

In the default configuration, all users across all user groups are now automatically prevented from reusing historical passwords. Learn how to further configure this password policy to make user passwords more secure.

New passwords entered by users are now checked against their historical passwords to ensure that previously used credentials aren't reused. You can configure the default behavior through the following properties:

password.policy.historical.enabled

Enables the feature of blocking the reuse of historical passwords. (Default value: true.)

password.policy.historical.groups.included

Specifies user groups whose users are prevented from reusing historical passwords. (default value: * – applies to all user groups.)

password.policy.historical.groups.excluded

Specifies user groups whose users aren't prevented from reusing historical passwords. (No default value.)

password.policy.historical.limit

Specifies a number of previous passwords new passwords are checked against. The value includes the current password. For example, when the property is set to 4, the current and the three last passwords are considered. If the property is set to 1, only the current password is checked against the new password. (default value: 4.)

Improve security by:

1. Setting an expiry date for unused initial Backoffice passwords to prevent idle users from signing in.

   Set an expiry date for unused initial passwords to prevent idle Backoffice users in selected user groups from signing in. If a new user hasn't signed in to Backoffice using an initial password for a number of days specified in the configuration of this security policy, the system doesn't allow the user to sign in and they need to contact their system administrators for a new password. Initial passwords are generated for all new Backoffice users who are prompted to change their password through Change Password After Expiry Feature on first sign-in.

   Note

   The option to change expired passwords isn't available in SmartEdit where users are instructed to sign in to Backoffice to resolve any outstanding password issues.

2. Setting an expiry date for unused passwords to prevent idle internal users from logging in.

   Set an expiry date for unused passwords to prevent idle internal users in selected user groups from logging in. If a user hasn't signed into an internal portal, for example, Backoffice, for a number of days specified in the configuration of this security policy, the system doesn't allow them to log in and the user needs to change their password through the forgotten password feature.

   Note

   This policy has no effect on the validity of initial passwords. To configure expiration of initial passwords, see Configurable Expiration of Initial Passwords with Group-Based Validity Periods.

3. Setting different validity periods of passwords for selected user groups, preventing logins post-expiry until a password change occurs.

   The password expiration policy allows you to configure different validity periods of passwords for internal users in selected user groups. After a period of time specified by the configuration of this policy, users aren't able to log in and need to change their password through the forgotten password feature.

In Backoffice, users with expired passwords aren't able to change their passwords themselves and need to contact their system administrators and request new passwords.

Configure the validity period of passwords in Backoffice in the User Groups > Administration configuration in the

• Initial password expiry period in days field.
• Inactive password expiry period in days field.
• Password expiry period in days field.

If there's no expiry date configured, SAP Commerce Cloud uses the fallback value provided by one of these properties:

• platform.authentication.initialPassword.unchanged.expiry.fallback.days
• platform.authentication.inactive.password.expiry.fallback.days
• platform.authentication.password.unchanged.expiry.fallback.days

The default value is 36135 days (99 years). If you don't want to set an expiration period of passwords of idle users for a specific user group, use 0 as a value of that group's validity period.

To improve security, user passwords can no longer be saved as plaintext or with an asterisk (*) in the database. The asterisk is now resolved to its actual encoding algorithm so the proper encoding key is saved instead.

Plaintext encoding is no longer allowed. The system now automatically applies the default encoding algorithm to any password that would have previously been stored in plaintext. Dedicated checks have been implemented to detect plain encoding attempts. When such an attempt is discovered, the system seamlessly intervenes by applying the default encoding algorithm to the password. It also replaces any reference to "plain" encoding with the name of the default algorithm used.

The implementation of the asterisk (*) encoding symbol has changed. Previously, it served as a configurable placeholder for various encoding algorithms, allowing system administrators to modify the mapping. This flexibility came with potential risks, as altering the algorithm associated with the asterisk could inadvertently disrupt user login processes for existing accounts.

To address these concerns, the system now maps the asterisk encoding to a specific default encoding in the background. This approach resolves the actual encoding while maintaining compatibility with existing user data. Instead of storing the asterisk symbol itself, the system now saves the name of the algorithm being used. The use of the asterisk for encoding new passwords has been discontinued.

Additionally, the UserPasswordTranslator class has been updated to follow the same configuration settings for password hashing as other parts of the system.

Passwords set through ImpEx are now audited for validity in all cases for both user creation and password updates. Therefore, the new configuration, which prevents passwords from being saved with asterisks, cannot be bypassed when using ImpEx to import new users or data. The system now consistently saves passwords according to the set password encoding, regardless of the method used (Backoffice or ImpEx).