8.3: 1. All user access to system components for users and administrators is authenticated via at least one of the following authentication factors: (a) Something you know, such as a password or passphrase, (b) Something you have, such as a token device or smart card, (c) Something you are, such as a biometric element.
  • Examine documentation describing the authentication factor(s) used to verify that user access to system components is authenticated via at least one authentication factor specified in this requirement.
  • For each type of authentication factor used with each type of system component, observe an authentication to verify that authentication is functioning consistently with documented authentication factor(s).

Description

Purpose

When used in addition to unique IDs, an authentication factor helps protect user IDs from being compromised, since the attacker needs to have the unique ID and compromise the associated authentication factor(s).

Good Practice

A common approach for a malicious individual to compromise a system is to exploit weak or nonexistent authentication factors (for example, passwords/passphrases). Requiring strong authentication factors helps protect against this attack.

Further Information

See fidoalliance.org for more information about using tokens, smart cards, or biometrics as authentication factors.

8.3: 2. Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.
  • Examine vendor documentation and system configuration settings to verify that authentication factors are rendered unreadable with strong cryptography during transmission and storage.
  • Examine repositories of authentication factors to verify that they are unreadable during storage.
  • Examine data transmissions to verify that authentication factors are unreadable during transmission.

Description

Purpose

Network devices and applications have been known to transmit unencrypted, readable authentication factors (such as passwords and passphrases) across the network and/or store these values without encryption. As a result, a malicious individual can easily intercept this information during transmission using a “sniffer,” or directly access unencrypted authentication factors in files where they are stored, and then use this data to gain unauthorized access.

8.3: 3. User identity is verified before modifying any authentication factor.
  • Examine procedures for modifying authentication factors and observe security personnel to verify that when a user requests a modification of an authentication factor, the user’s identity is verified before the authentication factor is modified.

Description

Purpose

Malicious individuals use "social engineering” techniques to impersonate a user of a system — for example, calling a help desk and acting as a legitimate user—to have an authentication factor changed so they can use a valid user ID.

Requiring positive identification of a user reduces the probability of this type of attack succeeding.

Good Practice

Modifications to authentication factors for which user identity should be verified include but are not limited to performing password resets, provisioning new hardware or software tokens, and generating new keys.

Examples

Methods to verify a user’s identity include a secret question/answer, knowledge-based information, and calling the user back at a known and previously established phone number.

8.3: 4. Invalid authentication attempts are limited by: (a) Locking out the user ID after not more than 10 attempts, (b) Setting the lockout duration to a minimum of 30 minutes or until the user’s identity is confirmed.
  • Examine system configuration settings to verify that authentication parameters are set to require that user accounts be locked out after not more than 10 invalid logon attempts.
  • Examine system configuration settings to verify that password parameters are set to require that once a user account is locked out, it remains locked for a minimum of 30 minutes or until the user’s identity is confirmed.

Description

Purpose

Without account-lockout mechanisms in place, an attacker can continually try to guess a password through manual or automated tools (for example, password cracking) until the attacker succeeds and gains access to a user’s account.

If an account is locked out due to someone continually trying to guess a password, controls to delay reactivation of the locked account stop the malicious individual from guessing the password, as they will have to stop for a minimum of 30 minutes until the account is reactivated.

Good Practice

Before reactivating a locked account, the user’s identity should be confirmed. For example, the administrator or help desk personnel can validate that the actual account owner is requesting reactivation, or there may be password reset self- service mechanisms that the account owner uses to verify their identity.

8.3: 5. If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows: (a) Set to a unique value for first-time use and upon reset, (b) Forced to be changed immediately after the first use.
  • Examine procedures for setting and resetting passwords/passphrases (if used as authentication factors to meet Requirement 8.3.1) and observe security personnel to verify that passwords/passphrases are set and reset in accordance with all elements specified in this requirement.

Description

Purpose

If the same password/passphrase is used for every new user, an internal user, former employee, or malicious individual may know or easily discover the value and use it to gain access to accounts before the authorized user attempts to use the password.

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) A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters), (b) Contain both numeric and alphabetic characters.
  • Examine system configuration settings to verify that user password/passphrase complexity parameters are set in accordance with all elements specified in this requirement.

Description

Purpose

Strong passwords/passphrases may be the first line of defense into a network since a malicious individual will often first try to find accounts with weak, static, or non-existent passwords. If passwords are short or easily guessable, it is relatively easy for a malicious individual to find these weak accounts and compromise a network under the guise of a valid user ID.

Good Practice

Password/passphrase strength is dependent on password/passphrase complexity, length, and randomness. Passwords/passphrases should be sufficiently complex, so they are impractical for an attacker to guess or otherwise discover its value. Entities can consider adding increased complexity by requiring the use of special characters and upper- and lower-case characters, in addition to the minimum standards outlined by this requirement. Additional complexity increases the time required for offline brute force attacks of hashed passwords/passphrases.

Another option for increasing the resistance of passwords to guessing attacks is by comparing proposed password/passphrases to a bad password list and having users provide new passwords for any passwords found on the list.

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.
  • Examine system configuration settings to verify that password parameters are set to require that new passwords/passphrases cannot be the same as the four previously used passwords/passphrases.

Description

Purpose

If password history is not maintained, the effectiveness of changing passwords is reduced, as previous passwords can be reused over and over. Requiring that passwords cannot be reused for a period reduces the likelihood that passwords that have been guessed or brute-forced will be re- used in the future.

Passwords or passphrases may have previously been changed due to suspicion of compromise or because the password or passphrase exceeded its effective use period, both of which are reasons why previously used passwords should not be reused.

8.3: 8. Authentication policies and procedures are documented and communicated to all users including: (a) Guidance on selecting strong authentication factors, (b) Guidance for how users should protect their authentication factors, (c) Instructions not to reuse previously used passwords/passphrases, (d) Instructions to change passwords/passphrases if there is any suspicion or knowledge that the password/passphrases have been compromised and how to report the incident.
  • Examine procedures and interview personnel to verify that authentication policies and procedures are distributed to all users.
  • Review authentication policies and procedures that are distributed to users and verify they include the elements specified in this requirement.
  • Interview users to verify that they are familiar with authentication policies and procedures.

Description

Purpose

Communicating authentication policies and procedures to all users helps them to understand and abide by the policies.

Good Practice

Guidance on selecting strong passwords may include suggestions to help personnel select hard-to-guess passwords that do not contain dictionary words or information about the user, such as the user ID, names of family members, date of birth, etc.

Guidance for protecting authentication factors may include not writing down passwords or not saving them in insecure files, and being alert to malicious individuals who may try to exploit their passwords (for example, by calling an employee and asking for their password so the caller can “troubleshoot a problem”).

Alternatively, entities can implement processes to confirm passwords meet password policy, for example, by comparing password choices to a list of unacceptable passwords and having users choose a new password for any that match with one on the list. Instructing users to change passwords if there is a chance the password is no longer secure can prevent malicious users from using a legitimate password to gain unauthorized access.

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: (a) Passwords/passphrases are changed at least once every 90 days, OR, (b) The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.
  • If passwords/passphrases are used as the only authentication factor for user access, inspect system configuration settings to verify that passwords/passphrases are managed in accordance with ONE of the elements specified in this requirement.

Description

Purpose

Access to in-scope system components that are not in the CDE may be provided using a single authentication factor, such as a password/passphrase, token device or smart card, or biometric attribute. Where passwords/passphrases are employed as the only authentication factor for such access, additional controls are required to protect the integrity of the password/passphrase.

Good Practice

Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase and less time to use a compromised password.

Using a password/passphrase as the only authentication factor provides a single point of failure if compromised. Therefore, in these implementations, controls are needed to minimize how long malicious activity could occur via a compromised password/passphrase.Dynamically analyzing an account’s security posture is another option that allows for more rapid detection and response to address potentially compromised credentials. Such analysis takes a number of data points, which may include device integrity, location, access times, and the resources accessed to determine in real time whether an account can be granted access to a requested resource. In this way, access can be denied and accounts blocked if it is suspected that authentication credentials have been compromised.

Further Information

For information about using dynamic analysis to manage user access to resources, see NIST SP 800-207 Zero Trust Architecture .

8.3: 10. Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any single- factor authentication implementation), then guidance is provided to customer users including: (a) Guidance for customers to change their user passwords/passphrases periodically, (b) Guidance as to when, and under what circumstances, passwords/passphrases are to be changed.
  • Additional testing procedure for service provider assessments only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data, examine guidance provided to customer users to verify that the guidance includes all elements specified in this requirement.

Description

Purpose

Using a password/passphrase as the only authentication factor provides a single point of failure if compromised. Therefore, in these implementations, controls are needed to minimize how long malicious activity could occur via a compromised password/passphrase.

Good Practice

Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase and less time to use a compromised password.

8.3: 10.1. Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either: (a) Passwords/passphrases are changed at least once every 90 days, OR, (b) The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.
  • Additional testing procedure for service provider assessments only: If passwords/passphrases are used as the only authentication factor for customer user access, inspect system configuration settings to verify that passwords/passphrases are managed in accordance with ONE of the elements specified in this requirement.

Description

Purpose

Using a password/passphrase as the only authentication factor provides a single point of failure if compromised. Therefore, in these implementations, controls are needed to minimize how long malicious activity could occur via a compromised password/passphrase.

Good Practice

Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase and less time to use a compromised password.

Dynamically analyzing an account’s security posture is another option that allows for more rapid detection and response to address potentially compromised credentials. Such analysis takes a number of data points which may include device integrity, location, access times, and the resources accessed to determine in real time whether an account can be granted access to a requested resource. In this way, access can be denied and accounts blocked if it is suspected that account credentials have been compromised.

Further Information

For information about using dynamic analysis to manage user access to resources, refer to NIST SP 800-207 Zero Trust Architecture .

8.3: 11. Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used: (a) Factors are assigned to an individual user and not shared among multiple users, (b) Physical and/or logical controls ensure only the intended user can use that factor to gain access.
  • Examine authentication policies and procedures to verify that procedures for using authentication factors such as physical security tokens, smart cards, and certificates are defined and include all elements specified in this requirement.
  • Interview security personnel to verify authentication factors are assigned to an individual user and not shared among multiple users.
  • Examine system configuration settings and/or observe physical controls, as applicable, to verify that controls are implemented to ensure only the intended user can use that factor to gain access.

Description

Purpose

If multiple users can use authentication factors such as tokens, smart cards, and certificates, it may be impossible to identify the individual using the authentication mechanism.

Good Practice

Having physical and/or logical controls (for example, a PIN, biometric data, or a password) to uniquely authenticate the user of the account will prevent unauthorized users from gaining access to the user account through use of a shared authentication factor.