Effectiveness of Changing Passwords

PCI Requirement 8.2.5 works in conjunction with PCI Requirement 8.2.4 to create secure passwords. Because PCI Requirement 8.2.4 requires passwords/passphrases to be changed every 90 days, PCI Requirement 8.2.5 dictates that new passwords/passphrases can’t be the same as any of the last four passwords/passphrases used. This prevents users from trying to alternate between the same few passwords or not reset their password at all by using the same password over and over again. The PCI DSS further explains, “If password history isn’t 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 of time reduces the likelihood that passwords that have been guessed or brute-forced will be used in the future.”

During an assessment, your organization’s system configuration settings will be examined to verify that parameters are in place so new passwords/passphrases can’t be the same as any of the last four passwords/passphrases used.

When we have a requirement that says that we need to change our passwords every 90 days, we find that people will try to use the last password that they had or not reset their password at all by submitting the same password that they’re already using. I can admit that even I’ve done that in the past. From an application security perspective, PCI Requirement 8.2.5 requires that you retain the last four passwords that an individual has used. When the passwords are changed every 90 days, you can’t use the last four passwords for a year. From an assessment perspective, we’re looking at the applications that you’ve developed, commercial off-the-shelf applications, authentication store, and how the password settings prevent somebody from using previous passwords.

Password/Passphrase Expiration

PCI Requirement 8.2.4 expects your organization to change user passwords/passphrases at least once every 90 days. The PCI DSS explains, “Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to work on breaking the password/phrase.” You may think that a shorter password/passphrase expiration date would be more secure, but best practice states that 90 days is an appropriate period of time. A smaller window, like 30 days, can reduce usability and cause users to choose weak passwords.

To verify compliance with PCI Requirement 8.2.4, assessors will examine a sample of system configuration settings to see that you change user passwords/passphrases at least once every 90 days. Service providers must undergo additional testing of their internal processes to see that non-consumer customer user passwords/passphrases are required to change periodically and these users are given guidance on when, and under what circumstances, passwords/passphrases must change.

If I’m Hacker Joe and I have your username and password and I’m using your account, that’s a bad thing, right? From a minimum perspective, the longest Hacker Joe should have access to any account would be 90 days. The reason for that is when we look at PCI Requirement 8.2.4, it requires that you change your password every 90 days. This really becomes a security consideration if you make it every 30 days, because people might start writing their password down just because it’s so cumbersome. They might use “Password1” and then change it to “Password2” and the next time it’s “Password3.” Every 90 days is one of those requirements that you may want to do more, but understand the implication of that and how it could play out in your environment.

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.