Requirements for Password/Passphrase Complexity and Strength

Passwords/passphrases are your organization’s first line of defense, which is why PCI Requirement 8.2.3 states that your users’ passwords/passphrases must require a minimum of seven characters and contain both numeric and alphabetic characters. The combination of length and alphanumeric characters gives passwords/passphrases the complexity and strength to stand against attackers. The PCI DSS explains, “Malicious individuals will often first try to find accounts with weak or nonexistent passwords. If passwords are short or simple to guess, 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.”

Although PCI Requirement 8.2.3 asks that passwords/passphrases must require a minimum of seven characters and contain both numeric and alphabetic characters, sometimes due to technical limitations, these minimum requirements cannot be met. In these cases, passwords/passphrases must have complexity and strength at least equivalent to the parameters specified by PCI Requirement 8.2.3.

The password settings and password requirements that you have within your environment need to be set to a minimal level of standards. Understand that the PCI DSS should not be considered the gold standard by any means, a lot of people might even consider it a copper standard. I’ve even talked to people that have said it’s more like a PVC standard around the level of security that we’re expecting.

The PCI DSS requires that passwords require at least seven characters and that there are alphanumeric requirements within the password. That’s what’s required; I would recommend to you, though, to teach your staff how to create a passphrase rather than just a password. There are things out there called rainbow tables; if a hacker gets ahold of the hashes, the passwords have been calculated out to 13 and 14 characters. I would recommend at least eight or nine characters for a minimum setting from a organizational security perspective. The PCI DSS requires that you only have a minimum of seven characters and that they contain alphanumeric characters. There are some caveats to this. If you ever read the guidance to PCI Requirement 8.2.3, it talks about password entropy and password equivalency. If you have an application or an environment that cannot meet the password requirements, there are things that you can do to meet this particular requirement by using password equivalency or password entropy.

Preventing Social Engineering

PCI Requirement 8.2.2 states, “Verify user identity before modifying any authentication credential.” How could this play out at your organization? Let’s imagine that you need a password reset, so you call a help desk and tell them the situation. If they unlocked your account and helped you reset the password, no questions asked, then what would stop an attacker from calling the help desk and asking the same thing? Your organization must have a process in place to verify user identity before modifying any authentication credential. The PCI DSS suggests having a shared password or secret question that only a proper user would know how to answer, which would verify user identity.

The intent of PCI Requirement 8.2.2 is to prevent social engineering. Social engineering is a type of attack that relies on human interaction and behavior to coax individuals into breaking normal security procedures. If an attacker poses as a user and tricks someone from your organization into giving them access to your environment, it’s left incredibly vulnerable. Implementing a process to verify user identity before modifying any authentication credential helps protect your organization from attacks like social engineering.

How many times have you heard about someone calling into the help desk and saying, “Hi, I’m Johnny Salesman. I fat-fingered my account. Can you please reset my password for me?” The help-desk people are trained to be helpful and supportive of their staff, and the first thing they might do is unlock that account, right? In most cases that’s fine, until the person that’s calling in and asking you to reset the account is Hacker Joe. In order to prevent that, we need to have a process in place where we authenticate the users in some capacity before we reset that password. That process of authentication is really up to you as an organization. It could be a shared password, it could be the management request – there are multiple ways you could go about authenticating individuals before resetting the password. The intent of this is to stop the social engineering attack and someone gaining access to an account that they should not have access to.

Strong Cryptography in Transmission and Storage

PCI Requirements 3 and 4 help your organization implement strong cryptography methods, and we see it again here in PCI Requirement 8. Using strong cryptography is essential to protecting cardholder data. An attacker can easily capture unencrypted passwords during transmission and while in storage, and use this data to gain unauthorized access to your system or to the cardholder data environment. To prohibit this interception, PCI Requirement 8.2.1 requires, “Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.”

To verify compliance with PCI Requirement 8.2.1, your organization’s vendor documentation and systems will be examined, along with a sample of your own system components, to ensure the use of strong cryptography to render all authentication credentials unreadable during transmission and storage. Service providers must undergo additional testing procedures so assessors can observe password files and confirm that non-consumer customer passwords are also unreadable during transmission and storage.

One of the holy grails of an attacker is to get to all of the usernames and passwords, because at that point it’s kind of game over. In order to prevent that type of thing from occurring, the PCI DSS requires two things around passwords. These passwords need to be encrypted when they’re being transmitted over your internal network, and they also need to be encrypted when they are stored.

Back in PCI Requirement 6.3, we talked about having an SDLC that takes PCI DSS into account. This might be one of those situations where you ask yourself, “How are we going to authenticate?” If you’re using a local authentication store, the passwords that you’re storing need to be stored in an encrypted format. From an assessor’s perspective, we’re going to look at all of your applications and how you’re authenticating. We’re then going to look at all of your authentication stores where your usernames and passwords reside and we’re going to look to see that they’re actually encrypted.

Proper User-Authentication Management

PCI Requirement 8.2 adds an additional layer of security to user IDs by requiring something you know, something you have, or something you are. It states, “In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users: 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).”

Understanding proper user-authentication management is easier than you might think. How many times have you entered a PIN after swiping your debit card this week? Your PIN is something you know. Has a website ever texted your phone a one-time password in order to gain access? That one-time password is something you have. Do you use a scan of your fingerprint to unlock your smartphone? Your fingerprint is something you are. The PCI DSS explains, “These authentication methods, when used in addition to unique IDs, help protect users’ IDs from being compromised, since the one attempting the compromise needs to know both the unique ID and the password (or other authentication used).”

To verify compliance with PCI Requirement 8.2, an assessor needs to examine the documentation that describes your organization’s authentication methods, then observe that the methods described are consistent with your system.

We started off talking in Requirement 8 about the need for everyone to get their own username and that no one shares their usernames. When we get to PCI Requirement 8.2, it basically says that everyone needs to have something to authenticate with. This can be a password, biometrics, a physical device. It doesn’t really matter what it is that your organization uses for authentication, it matters that everyone has something that they use to authenticate with.

Inactive Sessions

I’m sure you’ve witnessed or heard about situations where someone gets up from their workstation, but their session doesn’t log out. Inevitably, someone else uses their workstation to send an embarrassing or prank email on their behalf. But, what if it wasn’t something funny or embarrassing? What if a malicious user used your workstation and gained access to cardholder data? When users walk away from an open machine that has access to critical system components and/or cardholder data, that machine could be used by others in the user’s absence, resulting in unauthorized account access and/or misuse. This is where PCI Requirement 8.1.8 comes into play.

PCI Requirement 8.1.8 states, “If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.” This applies to your organization’s firewalls, routers, networking gear, and other equipment within your environment. An assessor will examine system configuration settings to verify that you require re-authentication after 15 minutes of inactivity. This doesn’t necessarily mean that the session has been terminated, but that the user will need to re-authenticate in order to access that session.

I’m sure we’ve all heard or seen about situations where somebody gets up from their workstation or laptop and it doesn’t log out. Somebody goes over and sends an email on their behalf about something embarrassing or whatever the case may be. We want to be sure that if you get up and walk away from your PC, that if your session has been idle for more than 15 minutes, that session times out.

From an operating system perspective, typically what we’ll look for is that you have a screensaver enabled. That screensaver needs to come on within 15 minutes. Once again, understand that this is not just about your workstation. If you’re going to be remoting into your firewalls, your routers, your networking gear, and all of the other equipment that you might have within your environment – those sessions are subject to this as well.

From an assessment perspective, we’re looking at how you’ve configured your firewalls, your routers, your servers, your applications, and if those sessions exceed 15 minutes or more, it should be timed out. This doesn’t necessarily mean that your session has been terminated, it just means you’re going to need to re-authenticate back into it in order to re-access that session.