if password is in clear text and easily viewable...

[rgreen]

I'm a little confused. Do payment applications pass PA-DSS audit even if password can be seen in the XML files or ini files of the payment application?

Let me give an example:

A MAJOR ($$$$) payment application sold by a member of the PCI board council (or so they claim) has specific instructions in its manuals to type in the root or admin password as part of the script that you need to run in order for the app to function properly. There are other areas where you need to input the passwords of user accounts in its batch scripts also. And yet, they have a document that says that they are PCI compliant.

So, what gives?

[jbhall56]

Requirement 3.3 of the PA-DSS states that payment applications must "Render payment application passwords unreadable during transmission and storage, using strong cryptography based on approved standards"

They must have some sort of compensating control in place that gets them around the requirement. That compensating control should be documented in their Implementation Guide. I'm guessing that they require that all of their communications be conducted over encrypted communications.

[rgreen]

Requirement 3.3 of the PA-DSS states that payment applications must "Render payment application passwords unreadable during transmission and storage, using strong cryptography based on approved standards"

They must have some sort of compensating control in place that gets them around the requirement. That compensating control should be documented in their Implementation Guide. I'm guessing that they require that all of their communications be conducted over encrypted communications.

So, let me get this straight... as long as the Payment app requires that customers install VPN and firewalls in between comm, it's ok to store passwords in plain text? What about ini files and log files? What if the logs show password changes in clear text (only when new passwords are changed)?

[lyalc]

So, let me get this straight... as long as the Payment app requires that customers install VPN and firewalls in between comm, it's ok to store passwords in plain text? What about ini files and log files? What if the logs show password changes in clear text (only when new passwords are changed)?

Generally it is not Ok.
In specific installations or configurations, there may be other security control, more stringent that the minimum criteria defined in PCI DSS that act to provide, in the QSA's view, equivalent security outcomes.

In the context of log files, ini files etc, unencrypted passwords are generally not acceptable. In some cases, stringent read/write file permissions, storage encryption and or highly restricted network access etc may be as effective - but this is usually an installation specific outcome, not generic to an application in any site.

All the above is conjecture based on the generality of information currently available - and as you have concerns it may be prudent to discuss further with the vendor, your client or the PCI Council.
I assume it is not prudent to disclose further specific details in this public environment.

lyalc

[stewart05]

If they had an audit performed by a PAQSA, and if they passed they should be on one of these 2 lists:
http://usa.visa.com/download/merchants/validated_payment_applications.pdf
https://www.pcisecuritystandards.org/security_standards/vpa/

If they are not on either of these lists, they either failed or didn't actually have an audit performed where the QSA submitted the AOV.

[jbhall56]

So, let me get this straight... as long as the Payment app requires that customers install VPN and firewalls in between comm, it's ok to store passwords in plain text? What about ini files and log files? What if the logs show password changes in clear text (only when new passwords are changed)?

No, I was at a loss for a good example and that was the first thing I thought of.

However, a compensating control is valid for a PA-DSS certification. I'm not sure how they would get there, but if the application was certified, there must have been some sort of compensating control used.