The value found in user and company data is highly sought after, especially by malicious actors. Personal information such as account credentials or credit card numbers can lead to direct theft or fraud, impacting both the individuals whose data is compromised and the companies who let it be. Because of this value, it is of the utmost importance to remain up-to-date on cybersecurity best practices. The PCI DSS 4.0 password requirements have been specifically developed to combat evolving threats to cardholder data across every industry—read on to learn about them.
Complying with the PCI DSS 4.0 Changes
The goal of updating data security standards is to prevent a data breach, as briefly mentioned above. The Payment Card Industry (PCI) Data Security Standard (DSS) serves as a baseline of control, including password protections, among many other safeguards. Version 4.0, released in 2022, builds upon controls in v3.2.1. To help you understand how to satisfy them, this blog will:
- Define current password standards as well as the improved 4.0 changes
- Review multifactor authentication protocols that build on password safety
- Take an in-depth look at PCI DSS 4.0 requirement 8 (MFA Requirements)
These changes aim to add another barrier of entry against attackers and work to assign a specific identity to approved users while authenticating access to system components.
Request a Free Consultation
Stronger Password Length Requirements
As the technology industry continues to evolve rapidly, it is to be expected that cybercriminals and malicious actors will evolve with it. Password strength is a baseline necessity to prevent “brute-force” attacks, in which a malicious actor guesses a computer system’s passphrase.
One of the primary changes in the PCI DSS 4.0 update is an increase in required password length. The new standard, agreed upon by technology leaders, is a minimum of 12 characters.
By utilizing numbers, upper and lowercase letters, as well as unique symbols, a password of 12 characters will take a hacker 34,000 years to crack by one estimate of password strength. In the previous PCI DSS 3.2.1 patch, the required password length was seven characters. So, by the same estimate, a unique password with the same ancillary character requirements but just seven characters would be subject to compromise via brute force in roughly 6 minutes.
This is why, at a base level, organizations will need to increase required password lengths, among other protections, to achieve and maintain PCI DSS compliance moving forward.
Multifactor Authentication
Multifactor Authentication (MFA), often referred to as two-factor authentication (2FA), is an added security measure that presents users with additional barriers to entry before granting access to a given account or asset. When MFA is implemented properly, it makes it difficult for a hacker to access information systems, even if a password or other credential is compromised.
MFA requires a second input, ideally unique to the authentic account owner, for access.
Some common and effective MFA methods utilized by companies across the tech industry, and recommended by the Cybersecurity & Infrastructure Security Agency (CISA), include:
- Text Message or Email – A message is sent directly to the email or phone number of the registered user, typically containing a link or a code they can use to verify access.
- Authenticator Application – A third-party app generates a code with an expiration timer (usually 30 seconds) to be entered into a confirmation box in the initial login portal.
- Push notification – Instead of a numerical code confirmation, a pop-up notification shows up on a secondary device (typically a phone) to verify the login attempt there.
- Fast Identification Online – Also known as FIDO, this is the strongest option. It utilizes biometrics such as facial recognition, a fingerprint or retinal scan, or voice recognition.
These are just some of the forms of MFA that are commonly used in today’s industry. Any one, or combination thereof, can drastically improve network security when implemented properly.
MFAs From 3.2.1 to PCI DSS 4.0
One of the premier features of PCI DSS v4.0 is the mandate for strong multifactor authentication for both users and administrators. This step may seem pretty straightforward on the surface, but when compared to v3.2.1, is a large shift towards the future of cybersecurity best practices.
Namely, MFA must now be utilized at every level of access for all accounts that have access to cardholder data (CHD). This contrasts with v3.2.1, in which MFA was required only in select instances, like for remote access outside of a business network and non-console uses of CHD, along with administrator access within the cardholder data environment (CDE).
Several sub-sections of Requirement 8 in the PCI DSS v4.0 state the following:
“Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication factors..”
This indicates a broader acknowledgement of MFA’s utility, reflected across Sub-requirement 8.4 (see below). The Security Standards Council (SSC) had formerly considered MFA apt for fewer situations, as noted above. Moving forward, MFA needs to be implemented more widely.
For a broader overview of changes in 4.0, see the PCI DSS 4.0 Summary of Changes.
Important PCI DSS 4.0 Changes – Requirement 8
One of the largest changes with the move to PCI DSS 4.0 from 3.2.1 is the flagship overhaul to Requirement 8, officially titled “Identify Users and Authenticate Access to System Components.“
The SSC has clearly laid out its stance on MFAs and their evolution in the industry. This is why they say Requirement 8’s purpose is to conform to two fundamental principles: establishing the identity of authorized users and enforcing verification of that identity before granting access.
To that end, Requirement 8 comprises six sub-requirements:
- 8.1 – Defining processes and mechanisms for the identification of users
- 8.2 – Managing all user accounts across their entire lifecycles
- 8.3 – Strengthening requirements for user authentication
- 8.4 – Implementing MFA across the cardholder data environment
- 8.5 – Preventing misuse of data within MFA systems
- 8.6 – Strengthening management of apps, accounts, and authentication factors
Establishing a user’s identity is done by associating an account with a registered identifier, usually a user login, application ID, or other system. These crafted IDs create a unique account for a user, and each user receives a unique “access code” to differentiate between them on the backend. This ensures that there is accountability within the system, as each action performed by a user is logged and granted specified access depending on their established “clearance.”
When this type of detailed (and thoroughly tracked) accountability is utilized, every single action taken on a system can be traced to the individual user—the ultimate goal of Requirement 8.
Sub-Requirement 8.1
The first subsection within 8.1 (8.1.1) lays out a rule that should be utilized in nearly every facet of an organization. Namely, all security policies and operational procedures that are identified need to be documented, kept up to date, routinely used, and known to all affected parties.
This clearly defines the expectations when implementing the rest of Requirement 8.
Building on this sub-requirement, 8.1.2 states that the roles and responsibilities for performing activities within Requirement 8 must also be documented, assigned, and understood. If every individual user is not made aware of day-to-day responsibilities and tasks, then they will not be completed in proper order. This is the foundation for all effective access control management.
Sub-Requirement 8.2
Sub-requirement 8.2 handles the proper use of user-facing authentication management for individuals that are either administrators or non-consumer users in the system. It exists to ensure that the individual accounts are not only maintained on a one-off basis but instead continually monitored through the account’s lifecycle—and safely disposed of at its end.
On top of ensuring continual maintenance, the subsections of 8.2 stress the importance of:
- Group, shared, or generic accounts, which should only be used when deemed necessary to limit harmful exposure as well as to enable simpler tracking (8.2.2).
- Clearly defining the parameters of service providers’ access to shared service environments, including but not limited to remote access points (8.2.3 & 8.2.7).
- The addition, deletion, and modification of user IDs and authentications, to be maintained through the lifecycle of the user at various stages of use/employment.
- Ensuring that user access privileges do not supersede or are otherwise misaligned with the account holder’s current roles, position, or employment status (8.2.4 & 8.2.5).
- Maintaining “inactivity” protocols, including terminating or disabling an account that has been inactive for 90 days or enforcing a re-authentication process should an individual be away from a terminal or session for longer than 15 minutes (8.2.6 & 8.2.8).
These subsections make up a large amount of the section 8 requirements. They work to limit the time and access that a harmful actor may have to a given system, short- and long-term.
Sub-Requirement 8.3
This sub-requirement is straightforward and smaller in scope. It works to provide a stronger defense by requiring more stringent authentication and passcode procedures. By employing measures such as MFA and minimum password lengths (detailed above), sub-requirement 8.3 ensures CHD data is protected during transmission and storage on all system components.
Other notable subsections among 8.3 include:
- Rules for cryptography for all authenticating factors (8.3.2)
- Limitations to the amount of login attempts a user has (8.3.4)
- Requirements for resetting said authenticating factors at regular intervals (8.3.9)
- Restrictions on reuse of any past credentials when resetting them (8.3.5 and 8.3.7)
These controls have slight differences in implementation and verification depending on the PCI Level you need to achieve, which depends on factors like your annual transaction volume. For example, a full Attestation of Compliance (AOC) using the Defined Approach would be tested differently than a Self Assessment Questionnaire (SAQ) using the Customized Approach.
Sub-Requirement 8.4
Sub-requirement 8.3.1 outlines the basic parameters of MFA use, but 8.4 explicitly lays out the full scope of MFA implementation. As previously mentioned, PCI DSS v3.2.1 had implemented requirements for MFA for remote use as well as non-console administrative use. However, in v4.0, MFAs are utilized at seemingly every level of system use. In particular, MFA applies to:
- All non-console access to the CDE, per 8.4.1
- More broadly, “all access into the CDE,” per 8.4.2
- External remote network access to the CDE, per 8.4.3
These protections are more comprehensive than their counterparts in earlier versions of the PCI DSS, accounting for more situations and greater specificity that should eliminate more instances where MFA requirements would not apply. At present, those exclusions are limited to automated programs and single-card data access, such as user accounts on point-of-sale (POS) terminals.
Sub-Requirements 8.5 and 8.6
Sub-requirement 8.5 states that MFA systems are to be configured to prevent misuse. When an organization poorly configures MFA systems, they leave the proverbial front door open to attack.
By requiring organizations to properly establish their MFA systems, PCI DSS 4.0 eliminates the susceptibility to replay attacks, which depend on capturing valid authentication to duplicate it later. It also prevents internal users from purposely or accidentally undermining MFA controls.
The final subsection found within Requirements 8 is 8.6. It mirrors 8.5 in preventing misuse, but its specifics relate to application and system accounts. Namely, 8.6 strictly enforces password requirements across all programs. Individual user, system, and application accounts require accountability to ensure that they are only used for their intended, secure purposes (8.6.1).
Per 8.5 and 8.6, the responsibility for proper password management passphrases lands on both the organization and the individual holder of the login information. Making sure all individuals uphold compliance at all levels is easiest when working with a PCI advisory partner.
Satisfy All PCI DSS 4.0 Password Requirements
The transition to the newest version from v3.2.1 is imminent. Compliance with 4.0 may not be required for a couple of years, depending on your last certification. But the final deadline of March 31, 2024, will be here in the blink of an eye. You’ll need to start optimizing password protections well in advance of that date to ensure seamless compliance into the future.
RSI Security is here to help you manage your passwords—and more.
Contact RSI Security today to schedule a consultation, implement controls, complete your PCI DSS 4.0 SAQ, or just learn how your organization can rethink its security implementation.
Download Our PCI DSS Checklist
Assess where your organization currently stands with being PCI DSS compliant by completing this checklist. Upon filling out this brief form you will receive the checklist via email.