If your company processes payments using credit cards, you’re required to maintain compliance with standards set out by the Payment Card Industry (PCI) Security Standards Council (SSC).
The PCI Data Security Standard (PCI DSS) has been in place since 2004. This publication gave rise to the SSC, which in turn published the first revision (version 1.1) in 2006. In the years following, these rules have undergone various changes; we’re currently on version 3.2.1.
In particular the guidelines for passwords and authentication have evolved significantly.
This guide will walk through what the password requirements are at present, how they’ve changed over time, and what they may look like in the future.
Update on PCI DSS 3.2 Password Security Requirements
One of the key elements of cybersecurity is password protection. This foundational tenet is part of every regulatory guide and cyberdefense scheme available, and PCI DSS is no different.
Like previous versions of the document PCI DSS v.3.2.1 requires that passwords are unique and user-generated rather than defaults or predetermined. It also sets specific parameters for what constitutes password and overall authentication strength, including regular resetting.
However, the specific ways that the PCI DSS has handled its password policies have changed pretty significantly over time.
Some of the most obvious changes have had to do with terminology.
While these changes to phrasing may seem slight or insignificant, they reflect bigger changes in the technology of passwords and overall authentication. These realities they reflect are significant in terms of what to expect in the years to come.
Let’s go over some key definitions before covering the overall requirements in depth.
Download Our PCI DSS Checklist
Evolving Terminology: Password, Passphrase, and Other Terms
Although they’re inseparable from our digital world, passwords are ancient technology.
The use of specific words or phrases to authenticate identity or enter a location predates the invention of computers. In ancient Rome they were called “watchwords” and used for military purposes. And the broader concepts of codes and cyphers are as old as civilization itself. The first computer password was invented in 1961, to be used with the early computer CTSS.
Using a word as a key is an old trick. But while the logic of authentication has remained the same over the millenia, the words used to describe the process have expanded and evolved.
PCI DSS Terminology Breakdown
In the PCI DSS a handful of terms related to passwords have been introduced over time:
- Authentication – Any particular method used to verify identity for access to a system or service, typically requiring one or more credentials.
- Password/ passphrase – A combination of characters that grants authentication:
- A password general includes letters, numbers, and some special characters
- A passphrase is generally longer, including all of these characters plus spaces
- Two-factor/ Multi-factor authentication (MFA) – A login procedure that requires two or more distinct authentication factors. For example:
- A password on one device, plus a verification from another device
Some of these phrases are interchangeable in many cases.
For example, while the difference between “password” and “passphrase” has to do with eligible characters, many institutions use the terms interchangeably. Also, in many cases, “multi-factor” authentication consists of just two factors.
However, there are important differences related to the cybersecurity ramifications of each term. Longer, more complicated passphrases are inherently safer than shorter passwords. And MFA is quickly overtaking passwords and passphrases entirely.
These and more relevant differences will be covered in detail below.
Assess your PCI compliance
PCI DSS Password Requirements in Version 3.2.1
The PCI DSS is a comprehensive cybersecurity scheme designed to safeguard against all kinds of threats to credit card information. Passwords are only one part of the broader equation. To understand how they fit into the scheme, it’s important to understand its overall scope.
The PCI DSS breaks down into 12 requirements, divided across six categories:
- Build and maintain a secure network and systems
- Requirement 1: A firewall configuration must be installed and maintained
- Requirement 2: Vendor-supplied system passwords must not be used
- Protect cardholder data
- Requirement 3: Stored cardholder data must be protected
- Requirement 4: Transmission of data across public networks must be encrypted
- Maintain a vulnerability management program
- Requirement 5: All systems must be safeguarded against malware
- Requirement 6: Secure systems and applications must be maintained
- Implement strong access control measures
- Requirement 7: Access to cardholder data must be restricted according to business need to know
- Requirement 8: Access to system components must be authenticated
- Requirement 9: Physical access to cardholder data must be restricted
- Regularly monitor and test networks
- Requirement 10: All access to network resources must be monitored
- Requirement 11: All security systems must be tested regularly
- Maintain an information security policy
- Requirement 12: A policy addressing information security must be maintained
Throughout this entire scheme, passwords are a key focus in two major areas: the second and eighth requirements. However, their importance is felt throughout the entire system.
Password Policy in Requirement 2
The first specific guidelines about passwords in the PCI DSS are actually about removing passwords—specifically, default passwords that are auto-generated for users by third parties.
Often, hardware and software are shipped with default or “dummy” user accounts enabled. These accounts use a generic username and password, like “USER” and “PASSWORD,” in order to facilitate easy access. While these accounts are intended to be re-configured by users as soon as possible, there are various reasons a user may neglect to do so immediately.
For a physical analogue, consider a company that manufactures customizable padlocks:
- The locks are shipped with a default access code (i.e. 1111, 1234, etc.)
- Instructions within the packaging teach the user how to change the code
- The user may choose to re-configure the lock, or not, depending on preference
- The default code is significantly less secure than a unique, user-generated code
Like the easy default code on a physical lock the kinds of generic passwords used for these defaults are often simple combinations that are published, widely known, or easily guessed.
That makes them a prime target for hackers and other cybercriminals.
So, it’s imperative that any and all auto-generated passwords and accounts are removed from a device or system before it is installed or otherwise integrated into the broader network. That’s the main focus of requirement two, and subdivisions within specify parameters of where and how this rule applies to various types of accounts and authentication.
Password Policy in Requirement 8
This is where the PCI DSS lays out its full-fledged password policy.
Requirement eight specifies parameters for not just passwords, but the planning and execution of the entire authentication system. This includes everything user-facing, from identification and passwords to other logistical elements of logging in, like lockouts and error messages. It also includes areas outside of user visibility, like storage and internal processing of accounts.
The most important parts of this requirement boil down to:
- Assigning a unique ID to all users
- Avoiding re-use of individual IDs, even after expiration
- Strongly encrypting all user credentials
- In both transmission and storage
- All IDs and passwords must be unreadable
- Tightly control login attempts, lockouts, and error messages
- Restrict number of attempts
- Disable login after a given number
- Use vague or generalized error messages
- Exercising control over creation and deletion of accounts
- Monitor unused accounts and deleting them after prolonged absence
- Training all account holders on elements of account safety
- Enable strong password auto-generation
- Provide resources for password strength analysis
- Provide ample description of password strength and best practices
- Maintaining standards for password strength and complexity
- Require at least seven characters
- Require use of both letters and numbers
- Require regular password resets (every 90 days)
- Disallow use of prior passwords (and combinations)
- Restricting certain sensitive access points to MFA
- To all remote access to all systems
- For all personnel, clientele, and third parties
- Safeguarding MFA, requiring two of three factors with no overlap:
- Something one knows (like a password)
- Something one owns (like a cellular device)
- Something one is (like a biometric)
Taken together, these sub-requirements make up the core of the PCI DSS password policy, governing exactly how passwords should work in order for you to maintain compliance.These standards ensure a uniform minimum level of cybersecurity across all companies that comply.
The rules haven’t always looked exactly like this, though.
The Evolution of PCI DSS Password Policy
As internet technologies have evolved over the past 16 years, the proliferation of internet services has made so many of life’s functions easier for millions of Americans. We can bank and make purchases from the comfort of our homes. Or even out on the go, from our phones.
But with all that convenience comes risk.
Our platforms and apps are now integrated into every facet of our lives, creating new points of entry and exposure with every added convenience. Cybercriminals’ methods of exploiting our vulnerabilities have only gotten more complex over time.
That’s why password safety has evolved over the years, especially in PCI-related contexts.
Password Policy History: from Version 1.1 to Version 3.2.1
Each new version of the PCI DSS offers changes that update its requirements, typically expanding or clarifying them to meet changes in security needs. In some cases, rules are condensed or split into diverging paths. Over the nine editions of the PCI DSS, specific changes are noted both in the document itself and in supplementary materials provided by the SSC.
While older versions’ specifications no longer apply, they do provide insight into the patterns of evolution. These, in turn, help businesses anticipate the next steps. .
Let’s review the history and most significant changes:
- Changes between v1.1-1.2 – Detailed in the v.1.2 summary of changes, these are mostly contained to terminology and encryption methods:
- V1.2 introduces an expansion of “password” to “password or passphrase.”
- It also expands encryption parameters, requiring all credentials to be completely unreadable in both storage and transmission.
- Changes between v1.2.1-2.0 – The v.2.0 summary breaks down these changes, which govern more terminology, as well as account management logistics:
- A focus on “authentication” is added, due to companies embracing alternative methods besides passwords and passphrases.
- Unique values and automatic reset of passwords after first use.
- Changes between v2.0 – 3.0 – Moving from v.2.0 to v.3.0 entailed deeper, broader changes for password policy:
- New in v.3.0, reset of default passwords is required immediately at installation; it also now applies to all passwords.
- In addition, “authentication” sees more use, whereas there is less focus on “passwords” in particular, continuing a trend started in v.2.0.
- Updates to strength and complexity requirements for passwords (to the current seven characters, including both numbers and letters)
- Added requirements for training for all account holders.
- Changes in v3.0-onward – Since v.3.0, there have been changes in v.3.1 and then more additions in 3.2 before relatively few changes in v.3.2.1. Here are the major changes since 2013:
- V.3.1 clarifies the reset threshold of 90 days.
- V.3.2 adds significant changes to MFA, introducing current specifications.
There haven’t been major updates since v.3.2; PCI DSS 3.2 password requirements are nearly identical to the current ones detailed above.
Based on these patterns, we can begin to predict what password policy may look like in the next PCI DSS, version 4.0, which is expected later on in 2020.
Potential PCI Password Policy in Version 4.0
What do these trends imply for the future of password policy under PCI DSS?
On the one hand, password requirements have become more detailed, specifying layers of strength and complexity for both passwords and the whole authentication system. We can expect to see these increase moving forward, perhaps with:
- More stringent requirements for password length
- Shorter thresholds before a reset is required
On the other hand, passwords themselves lose importance as MFA gains it.
Given the way that MFA has overtaken the password regulations, we can expect that trend to continue moving forward. There are likely to be further specifications laid out for MFA, such as a push for at least three factors, given the abandonment of “two-factor” as a useful term. There may also be more robust MFA training required.
Whatever the future of password policy holds, professional cybersecurity is the best way to ensure you’re compliant—and safe.
Compliance and Cybersecurity, Professionalized
Here at RSI Security, our mission is helping you maximize your cyberdefenses. That includes compliance with all relevant mandates. Our PCI DSS advisory services are a one-stop shop to keep you compliant and operational.
But compliance isn’t the end of cybersecurity; it’s just the beginning.
A robust cyberdefense system also includes a host of other cybersecurity measures, like monitoring your vulnerabilities and shoring up all possible exploits. Our expert analysts and technicians are here to craft the perfect cybersecurity solution, tailored exactly to the needs and means of your business.
Contact RSI today to see what a difference professional cybersecurity can make.
Schedule a free consultation