Required MFT Server Password Settings for PCI DSS Compliance - Part 1

This article was originally published on May 18, 2012 but was updated on September 12, 2018 to align with PCI DSS 3.2.1.

Overview

Certain PCI-DSS requirements dictate how passwords should be generated, managed and used in file transfer systems located within or connected to your cardholder data environment. In this post, we'll identify what those requirements are and then point to ways you can meet them when using JSCAPE MFT Server.

Let's jump into those requirements now.

Requirement #2: Prohibiting the use of vendor-supplied defaults for system passwords

Requirement #2 prohibits the use of vendor-supplied defaults for system passwords. This is to counter attackers who take advantage of the usual failure of admins to change the default passwords that come upon purchase of certain system components.

When you buy a system component (e.g. a server, software application, virtual appliance, etc.), that component will often already come with default passwords. The purpose of these passwords is to allow you to gain initial access into that component's internals.

Because vendors normally provide exactly the same password for every single copy of the same product, this kind of information easily finds its way into hacker communities. Many of these passwords even get published on the Internet.

Requirement 2.3: Strong encryption of non-console administrative access

Falling under the general requirement Requirement #2, Requirement 2.3 calls for the "encryption of all non-console administrative access using strong cryptography." The requirement encourages the use of technologies such as SSH, VPN, and later versions of TLS (TLS 1.2 and higher). SSL and early TLS versions aren't considered strong cryptography.

Note:The PCI DSS 3.2.1 Requirements and Security Assessment Procedures document directs readers to refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g., NIST SP 800-52 and SP 800-57, OWASP, etc.).

Administrative passwords, which normally hold the keys to business-critical components in your IT system, should never be transmitted through networks in the clear where they could be easily intercepted by eavesdroppers. To prevent transmitted passwords from falling into the wrong hands, the encryption technology your file transfer management system employs should be capable of applying encryption before transmission of such information.

Requirement 6.3.1: Removal of custom application accounts and their corresponding passwords before deployment

During software development, developers may create custom applications accounts, user IDs, and passwords. If they are not removed from production code before the application is released to the customer, they can give away too much information as with regards to how the application functions internally. This will enable attackers to find vulnerabilities they can exploit.

Requirement 6.5.5: Improper error handling

Error messages displayed by your system should not give away too much information. In the case of login passwords, the error message displayed as a result of a wrong password need not be overly helpful to the person logging in. A message such as "incorrect password provided" is already suggesting that the username entered was already correct.

So if that person is an attacker, he could just focus his efforts on the password, which would of course make it easier for him than if he would have had to guess both the username and password.

Requirements 8.1.6 and 8.1.7: Locking out a user after successive failed access attempts

8.1.6 talks about limiting repeated access attempts to 6. Once a user reaches that limit, that user should be locked out. Otherwise, an attacker attempting to break in could simply go on and on, entering different usernames and passwords until he comes up with the correct match. The attacker can even automate this process through what is known as a brute force attack.

8.1.7, on the other hand, talks about the time duration over which the user should be locked out after making 6 failed access attempts. The recommended lockout duration is at least 30 minutes or until an admin enables the user account. This is one way of discouraging attackers from continuing their break-in attempts and to give ample time to the admin to investigate the matter.

Requirement 8.2: Use of passwords or other methods of authentication in addition to unique IDs

This is easy to understand. Requirement 8.2 simply calls for the use of passwords (or other methods of authentication) in addition to unique IDs (a.k.a. usernames) when authenticating users who want to gain access to your managed file transfer server.

Requirement 8.2.1: Rendering all passwords unreadable during transmission through strong cryptography

This is similar to Requirement 2.3, except that this one applies to your end users. And really, for file transfer servers, the connections made by end users will be far greater in number than connections made by your server admin. If these connections are left unprotected, attackers can make a killing with your users' login credentials. This would give them a stockpile of hacking data that they could use in many future intrusions.

Requirement 8.2.2: Verifying user identity before doing password resets

Not all attackers will resort to super-duper technical methods to get to your credit card data. Some of them will do it the old-fashioned way, which now goes by the fancy name of "social engineering". For example, they can call your Help Desk, pose as a legit user, and request a password reset for that user's account. If they succeed in fooling your Help Desk agent, your agent will give them a temporary password which they can use to login to the account.

It's therefore important to have a way of verifying a user's identity before approving any password reset request, especially if the request is done via a phone call, an email, ticket, or any method where you can't meet the person face-to-face.

Requirements 8.2.3 - 8.2.5: Forcing users to adhere to a strong password policy

Passwords are the first line of defense of your secure file transfer system. If your user accounts have weak or, worse, no passwords at all, attackers can easily enter your system. PCI DSS explicitly specifies the following requirements for strong passwords:

• 8.2.3 Require a minimum password length of 7 characters, and
• 8.2.3 Use passwords containing both numeric and alphabetic characters
• 8.2.4 Change user passwords at least every 90 days.
• 8.2.5 Prohibit each individual from submitting a new password that is the same as any of the last 4 passwords that that same individual has already used.
• 8.2.6 Set passwords/passphrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use.

When I perform my JSCAPE MFT Server experiments in my own personal lab, I use exactly the same password for every hypothetical user I create. But I won't be surprised if you do that too each time you create a new user or when you do a password reset on an existing user in an actual production environment. That's very dangerous.

That will make your managed file transfer server vulnerable to possible attacks from malicious employees or ex-employees who are familiar with your practice as well as the passwords you often employ. Worse, if you are fond of using customary temporary passwords like "password" or "passwd", even outsiders can have a good chance of getting into your system.

The best way would be to always issue unique passwords and then have end users change them after first use.

8.3 Using multi-factor authentication in non-console administrative access and all remote access

Multi-factor authentication decreases the risk of unauthorized logins considerably. It does so by asking the user to prove his/her identity by submitting at least 2 requirements instead of the usual 1 (i.e. a password). In most cases, a multi-factor authentication login system would require 2 or more of the following:

• Something the user knows (e.g. a password or passphrase)
• Something the user has (e.g. a private key or token)
• Something the user is (e.g. a fingerprint or other biometric)

Requirement 8.5.8: Prohibiting group, shared, or generic accounts and passwords

If you assign the same username and password to a group of people, it would be impossible for you to enforce accountability. It would be very difficult to tell who among the members of the group actually logged in at a particular time and did this or that. So for example, even if you are able to trace leaked credit card information to a particular username, you still won't be able to tag the exact culprit.

Now that you know which PCI DSS requirements deal with passwords, the next step in achieving compliance with these requirements on your JSCAPE MFT Server would be to configure your server accordingly. Learn how to do it by proceeding to Part 2.