8: Identify Users and Authenticate Access to System Components

Requirement 8.2.1

All users are assigned a unique ID before access to system components or cardholder data is allowed.

The term subsequent changes used throughout Requirement 8 refers to any application changes that result in user accounts reverting to default settings, changes to existing account configurations, and changes that generate new accounts or re-create existing accounts.

These password controls are not intended to apply to personnel who only have access to one card number at a time to facilitate a single transaction. These controls are applicable for access by personnel with administrative capabilities, for access to systems with cardholder data, and for access controlled by the payment application. This requirement applies to the payment application and all associated tools used to view or access cardholder data.

IBM® Safer Payments meets this requirement. IBM Safer Payments enforces secure authentication for all authentication credentials that the application generates by:

  • Enforcing secure changes to authentication credentials by the completion of installation.
  • Enforcing secure changes for any subsequent changes (after installation) to authentication credentials.

Remarks:

  • You must not use any administrative/root user accounts for daily operational use.
  • You must assign secure authentication to any default accounts (even if they are not used), and then disable them. Use the PCI DSS compliance report to verify that all default user accounts are addressed correctly.
  • If you use an LDAP server to manage user passwords, you must make sure that the LDAP server is configured according to the requirements.
  • If you use the SMTP-based emailing capabilities of IBM Safer Payments, you must make sure that the SMTP server is configured according to the requirements.
  • If you use OpenID connect (OIDC) token for user authentication, you must make sure that the authorization infrastructure is configured according to all applicable requirements.

Requirement 8.2.2

Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows:
  • Account use is prevented unless needed for an exceptional circumstance.
  • Use is limited to the time needed for the exceptional circumstance.
  • Business justification for use is documented.
  • Use is explicitly approved by management.
  • Individual user identity is confirmed before access to an account is granted.
  • Every action taken is attributable to an individual user.

Safer Payments meets this requirement. It does not require or use any group, shared, or generic accounts and passwords.

Requirement 8.2.3

Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises.

Currently, remote access to a customer's environment is not allowed for vendors or integrators/resellers.

Requirement 8.2.7

Accounts used by third parties to access, support, or maintain system components via remote access are managed as follows:
  • Enabled only during the time period needed and disabled when not in use.
  • Use is monitored for unexpected activity.

This requirement applies only if the licensee accepts updates to be delivered using remote access. To be PCI DSS compliant, such remote access must be turned on only temporarily, and when needed. It must be turned off immediately after use. Notwithstanding, PCI DSS Requirement 1 must always be met.

Use a securely configured firewall or a personal firewall product, if the computer is connected over VPN or other high-speed connection, to secure these “always-on” connections, per PCI DSS Requirement 1.

Requirement 8.2.8

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

IBM Safer Payments meets this requirement by providing an option in the system configuration defining the number of seconds of idle time after which a session expires causing an automatic log out.

Requirement 8.3.1

All user access to system components for users and administrators is authenticated via at least one of the following authentication factors:

  • 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 element.

IBM Safer Payments meets this requirement by using password-based authentication.

For the organization of the licensee to be PCI DSS compliant, all access to PCs, servers, and databases with payment applications and cardholder data must require a unique user ID and PCI DSS compliant secure authentication. You must ensure that this requirement is met by organizational guidelines.

The IBM Safer Payments application itself complies with this requirement. In particular, each user can use a unique user ID, and authentication in accordance with Requirement 3.1 is implemented. However, the licensee must ensure by using organizational guidelines that users do not share accounts, and secure authentication is ensured through PCI DSS compliant configuration of the software.

Requirement 8.3.2

Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.

To render passwords unreadable during transmission, communication between the workstations of the users and the IBM Safer Payments instances, and between IBM Safer Payments instances, must be encrypted. For example, by using the internal SSL encryption function of IBM Safer Payments.

If LDAP integration is used with IBM Safer Payments, passwords are transmitted to the LDAP server. For secure transmission, turn on LDAP encryption over SSL on the Administration > System > Configuration > User page, as shown in Figure 1 .

Figure 1. Authentication Settings (LDAP)
This screen capture is described in the surrounding text.

You can use the PCI DSS compliance report to verify the compliance of this option in your Safer Payments installation. For more information, see Running the PCI DSS compliance report.

Note: The input variable does not need to be unpredictable or secret.

Passwords are stored securely with IBM Safer Payments as salted PBKDF2 hashes. Every user has a unique 32 characters long random salt, which is set during user creation. To generate randomness, two boost functions are used, which take entropy from /dev/urandom. As random input characters the 62 case-sensitive alphanumeric characters are used. The strength of the salt is thus 1984 bit (32*62). The generated salt is combined with the user’s password and login and is hashed by a PBKDF2 hashing function that uses SHA512 as the message digest algorithm and performs 50027 iterations.

You can use the PCI DSS compliance report to verify the compliance of your IBM Safer Payments installation. For more information, see Running the PCI DSS compliance report.

Requirement 8.3.4

Invalid authentication attempts are limited by:
  • Locking out the user ID after not more than 10 attempts.
  • Setting the lockout duration to a minimum of 30 minutes or until the user’s identity is confirmed.

IBM Safer Payments meets this requirement by providing an option in the system configuration where the number of failed login attempts after which a user account is disabled is defined.

IBM Safer Payments meets this requirement by disabling a user account until an administrator manually reactivates it.

Requirement 8.3.6

If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity:
  • A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters).
  • Contain both numeric and alphabetic characters.

Safer Payments meets this requirement by providing options in the system configuration that for user passwords to have a minimum length, contain at least one uppercase character, contain at least one lowercase character, contain at least one digit, or contain at least one special character.

Requirement 8.3.7

Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.

IBM Safer Payments meets this requirement by providing an option in the system configuration where the number of past passwords that a new password is checked against is defined.

Requirement 8.3.9

If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either:
  • Passwords/passphrases are changed at least once every 90 days, OR
  • The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.

Safer Payments meets this requirement by providing an option in the system configuration where the number of days for which passwords are valid is defined.

Requirement 8.4

Multi-factor authentication (MFA) is implemented to secure access into the CDE.

Requirement 8.4.1

MFA is implemented for all non-console access into the CDE for personnel with administrative access.

You must implement processes to make sure that for all non-console administrative access multi-factor authentication is used.

Multi-factor authentication consists of at least two of the following:
  • Something you have, such as a token device or a smart card.
  • Something you are, such as a biometric identification.
  • Something you know, such as a password or a passphrase.

To achieve multi-factor authentication, you can either use a third-party solution or the built-in IBM Safer Payments solution, which is described in Creating certificates with OpenSSL.

Requirement 8.4.3

MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE as follows:
  • All remote access by all personnel, both users and administrators, originating from outside the entity’s network.
  • All remote access by third parties and vendors.

If the organization of the licensee enables remote access, this must be secured in accordance with requirement 10 by using multi-factor authentication.

IBM Safer Payments itself implements multi-factor authentication through the distribution of personalized client certificates, which must be imported with the browser that is being used. See Creating certificates with OpenSSL for details.

If your installation requires a multi-factor authentication, you can either use multi-factor authentication as provided by IBM Safer Payments or use a third party multi-factor solution. For example, a remote VPN access.