WebSphere Commerce on premise not applicable for Commerce on Cloud offering

Requirement 8: Identify and authenticate access to system components

The detailed requirements in this section are relevant to WebSphere Commerce. Review each point carefully.

8.1 Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components as follows:

8.1.1 Assign all users a unique ID before allowing them to access system components or cardholder data.

Every user in WebSphere Commerce has a unique user ID. To create a user, see:Creating a user

Note: Do not share administrative IDs such as wcsadmin. Create a separate user for each administrator, any user involved in payment processing, or any user with access to cardholder data.

8.1.2 Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.

All modification of user IDs is performed in the Organization Administration Console, which is controlled by password authentication and role-based permissions.

For more information:

Organization Administration Console

8.1.3 Immediately revoke access for any terminated users.

Once an account is disabled, the user can no longer logon to the WebSphere Commerce application. You should ensure that the user's operating system access and network access is also revoked.

8.1.4 Remove/disable inactive user accounts at least every 90 days.

You can remove inactive or disabled user accounts every 90 days by using the dbclean utility. You should create a schedule for this with your database administrator.

For more information on the dbclean utility:

Database Cleanup utility command script

8.1.5 Manage IDs used by vendors to access, support, or maintain system components via remote access as follows:
  • Enabled only during the time period needed and disabled when not in use.
  • Monitored when in use.

WebSphere Commerce does not enable or support remote access. If you choose to enable remote access to your network, you must implement 2-factor authentication.

8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts.

The default lockout threshold for administrators is 3 attempts, while for shoppers it is 6 attempts. For more information on the default account policies:

Default account policies

8.1.7 Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

Account lockout in WebSphere Commerce continues until an administrator re-enables the account.

8.1.8 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

WebSphere Commerce has a login timeout feature, which is enabled by default. If you need to re-enable this feature:

Enabling login timeout for a cookie-based session

8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:

  • Something you know, such as a password or passphrase
  • Something you have, such as a token device or smart card
  • Something you are, such as a biometric.

WebSphere Commerce users are authenticated with a password.

8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.

Passwords are stored in the database using a one-way hash, and then further encrypted. Passwords are encrypted during transmission over HTTP using SSL. To configure the Reset Password email to contain a validation code instead of a temporary plain text password, follow the following steps: Configuring storefront Reset Password feature to use validation codes.

8.2.2 Verify user identity before modifying any authentication credential--for example, performing password resets, provisioning new tokens, or generating new keys.

Password resets are sent to the e-mail account that the user submitted when registering. Shoppers are required to answer a challenge question submitted at registration.

8.2.3 Passwords/phrases must meet the following:
  • Require a minimum length of at least seven characters.
  • Contain both numeric and alphabetic characters.
Alternatively, the passwords/phrases must have complexity and strength at least equivalent to the parameters specified above.

Ensure that the password policy you are using in WebSphere Commerce requires at least seven characters. Administrators are required to use eight- character passwords by default. WebSphere Commerce passwords are required to contain both numeric and alphabetic characters.

For more information, see Default account policies.

8.2.4 Change user passwords/passphrases at least every 90 days.

Ensure that the password policy you are using in WebSphere Commerce requires a password change every 90 days. Administrators are required to change their password every 90 days by default. For more information, see Default account policies.

8.2.5 Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used.

WebSphere Commerce does not allow you to submit a new password that is the same as any of the last four passwords that he or she has used.

If you are using a custom authentication mechanism such as LDAP, you should test it to ensure compliance.

8.2.6 Set passwords/phrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use.

The WebSphere Commerce administrator account must be changed immediately after first use.

8.3 Incorporate two-factor authentication for remote network access originating from outside the network by personnel (including users and administrators) and all third parties, (including vendor access for support or maintenance).
Note: Two-factor authentication requires that two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication.

Examples of two-factor technologies include remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; and other technologies that facilitate two-factor authentication.

WebSphere Commerce does not enable or support remote access. If you choose to enable remote access to your network, you must implement 2-factor authentication.

Important: Any resellers or integrators you do business with must use and implement remote access security features. Examples of remote access security features include:
  • Change default settings in the remote access software (for example, change default passwords and use unique passwords for each customer).
  • Allow connections only from specific (known) IP/MAC addresses.
  • Use strong authentication and complex passwords for logins, according to PCI DSS requirements.
  • Enable encrypted data transmission according to PCI DSS requirements.
  • Enable account lockout after a certain number of failed login attempts according to PCI DSS requirements.
  • Configure the system so a remote user must establish a Virtual Private Network (VPN) connection via a firewall before access is allowed.
  • Enable the logging function.
  • Restrict access to customer passwords to authorized reseller/integrator personnel.
  • Establish customer passwords according to PCI DSS requirements.

8.4 Document and communicate authentication procedures and policies to all users including: Guidance on selecting strong authentication credentials Guidance for how users should protect their authentication credentials Instructions not to reuse previously used passwords Instructions to change passwords if there is any suspicion the password could be compromised.

The merchant is responsible for documenting and communicating the security policies and operational procedures to all affected parties.

8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:
  • Generic user IDs are disabled or removed.
  • Shared user IDs do not exist for system administration and other critical functions.
  • Shared and generic user IDs are not used to administer any system components.

Do not share access to the administrator accounts in WebSphere Commerce. Create a new account for each administrator. By default, user IDs in WebSphere Commerce cannot be logged in multiple times concurrently.

Password management in WebSphere Commerce is handled through Account Policies.

The default account policy for shoppers and administrators is described here:

Default account policies

Other useful topics:

8.5.1 Additional requirement for service providers: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.
Note: This requirement is not intended to apply to shared hosting providers accessing their own hosting environment, where multiple customer environments are hosted.

Requirement 8.5.1 is a best practice until June 30, 2015, after which it becomes a requirement.

Vendors should never need administration accounts in WebSphere Commerce. Ensure that the operating system accounts used by vendors are disabled when not in use.

8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows: Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts. Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.

WebSphere Commerce does not support these authentication mechanisms by default. It is the vendor's responsibility to ensure that only the intended account can use the authentication mechanism to gain access.

8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:
  • All user access to, user queries of, and user actions on databases are through programmatic methods.
  • Only database administrators have the ability to directly access or query databases.
  • Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).

All access to the WebSphere Commerce database is authenticated.

8.8 Ensure that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.

This is a responsibility of the merchant.