Managed File Transfer and Network Solutions

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

Posted by John V. on Wed, May 23, 2012 @ 02:14 PM


PCI DSS requirementsCertain 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 SSL/TLS.

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 the 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. 


Requirement 8.2: Use of passwords 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.4: Rendering all passwords 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.5.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. 


Requirement 8.5.3: Unique passwords for new users and for those requesting resets

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.


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.


Requirements 8.5.9 - 8.5.12: Forcing users to adopt strong passwords

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.5.9 Change user passwords at least every 90 days.

8.5.10 Require a minimum password length of 7 characters.

8.5.11 Use passwords containing both numeric and alphabetic characters

8.5.12 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.


Requirements 8.5.13 and 8.5.14: Locking out a user after successive failed access attempts

8.5.13 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.

8.5.14, on the other hand, talks about the time duration over which the user should be locked out after making 6 failed access attempts. 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.


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.

Topics: JSCAPE MFT Server, Managed File Transfer, Security, Compliance, PCI-DSS, Secure File Transfer