Requirement 3: Provide secure authentication features

Details about how requirement 3 and subrequirements 3.1, 3.2, 3.3, and 3.4 are fulfilled.

Requirement 3.1

The payment application must support and enforce the use of unique user IDs and secure authentication for all administrative access and for all access to cardholder data. Secure authentication must be enforced to all accounts generated or managed by the application by the completion of installation and for subsequent changes after installation. The application must enforce 3.1.1 through 3.1.11.

Note: The term subsequent changes used throughout Requirement 3 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.
Note: 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 PA-DSS requirements.
3.1.1. The payment application does not use (or require the use of) default administrative accounts for other necessary software (for example, the payment application must not use the database default administrative account).
IBM Safer Payments does not require any administrative privileges to run and it does not use any third-party software except the operating system.
Note: If you use OIDC tokens with an external authentication infrastructure, you must address this requirement for the communication between the user client and the authorization server.
3.1.2. The application must enforce the changing of all default application passwords for all accounts that are generated or managed by the application, by the completion of installation and for subsequent changes after installation. This applies to all accounts, including user accounts, application and service accounts, and accounts used by the vendor for support purposes.
IBM Safer Payments meets this requirement because it is delivered with one default user account and you must change the password at your first login to access the user interface.
3.1.3. The payment application assigns unique IDs for user accounts.
IBM Safer Payments meets this requirement. Unique IDs are assigned for user accounts.
3.1.4. The payment application employs at least one of the following methods to authenticate all users:
  • Something that you know, such as a password or passphrase.
  • Something that you have, such as a token device or smart card.
  • Something that you are, such as a biometric.

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

3.1.5. The payment application does not require or use any group, shared, or generic accounts and passwords.
IBM Safer Payments meets this requirement. It does not require or use any group, shared, or generic accounts and passwords.
3.1.6 The payment application requires that passwords meet the following:
  • Require a minimum length of at least seven characters.
  • Contain both numeric and alphabetic characters.

IBM Safer Payments meets this requirement by providing options in the system configuration that force 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.

3.1.7. The payment application requires changes to user passwords at least every 90 days.
IBM 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.
3.1.8 The payment application keeps password history and requires that a new password is different than any of the last four passwords 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.
3.1.9 The payment application limits repeated access attempts by locking out the user account after not more than six logon attempts.
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.
3.1.10 The payment application sets the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.
IBM Safer Payments meets this requirement by disabling a user account until an administrator manually reactivates it.
3.1.11 If a payment application session has been idle for more than 15 minutes, the application requires the user to reauthenticate to reactivate the 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.

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 3.2

Software vendor must provide guidance to customers that all access to PCs, servers, and databases with payment applications must require a unique user ID and secure 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 3.3

Secure all payment application passwords (including passwords for user and application accounts) during transmission and storage.

3.3.1 Use strong cryptography to render all payment application passwords unreadable during transmission.

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.

3.3.2 Use a strong, one-way cryptographic algorithm, based on approved standards to render all payment application passwords unreadable during storage. Each password must have a unique input variable that is concatenated with the password before the cryptographic algorithm is applied.
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 3.4

Payment application must limit access to required functions/resources and enforce least privilege for built-in accounts.

  • By default, all application/service accounts have access to only those functions/resources needed for purpose of the application/service account.
  • By default, all application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.

Use the IBM Safer Payments default user only to create new personalized user accounts and disable the default user immediately afterward.

IBM Safer Payments meets this requirement. IBM Safer Payments has a built-in role system that allows to define permissions for different user groups.

For more information, see Starting the first cluster instance and Setting user privileges.