Wildcat! PCI Support

Santronics Software, Inc.,
Wildcat! PCI Support

Introduction:

Starting with Wildcat! v6.3.453.2, support for PCI DSS (Payment Card Industry Data Security Standard) Wildcat! Web Server (WcWeb) compliant operations is available. Customer operations who are required to support PCI must follow the DSS guidelines which is verified and certified by PCI Auditors.

Overall, Wildcat! offers the following for PCI compliance:

PCI SSL Operations
PCI Web Authentication and Session Management
- Idle Timeouts
- PCI Login Token Cache
Strong User Password Storage Protection

PCI SSL Operations:

When PCI SSL compliance is enabled, SSLv3/TLSv1 and 128+ key bit length cipher suites are used for the Wildcat! SSL Web Server. SSLv2 is no longer used for SSL connections and web browsers attempting to use SSL v2 or a suite with less than 128 bits will not be allowed to connect. Depending on the browser, it can be a silent response or a browser specific page indication the connection error.

To enable PCI SSL compliance, under WCCCONFIG SSL Options a button "Set PCI Compliance" is available for the Web Server SSL setup only.

Clicking the "Set PCI Compliance" button will preset the WEB SSL settings required for PCI SSL compliance.

Note: Once a SSL setup change is made, only WCCONLINE (Wildcat! Online Controller) needs to be restarted.

The available SSLv3/TLSv1 128+ bit cipher suites under Wildcat! that are prepared for PCI compliance from weakest to strongest are:

   bits:  128 | AES128-SHA
   bits:  128 | DHE-DSS-AES128-SHA
   bits:  128 | DHE-DSS-RC4-SHA
   bits:  128 | DHE-RSA-AES128-SHA
   bits:  128 | IDEA-CBC-SHA
   bits:  128 | RC4-MD5
   bits:  128 | RC4-SHA
   bits:  168 | DES-CBC3-SHA
   bits:  168 | EDH-DSS-DES-CBC3-SHA
   bits:  168 | EDH-RSA-DES-CBC3-SHA
   bits:  256 | AES256-SHA
   bits:  256 | DHE-DSS-AES256-SHA
   bits:  256 | DHE-RSA-AES256-SHA

PCI Web Authentication And Session Management:

PCI web authentication and session management compliance requires:

Stronger authentication methods such as DIGEST-AUTH or COOKIE-AUTH authentication be used.
SSL encryption should be used (see PCI SSL Operations)
One time login authentication and authorization credentials.
User logouts due to idle Timeouts force new logins.

Overall, once the user is logged off or idle timeouts, the same authentication and authentication credentials can not to be used again or replayed by another client.

To enable PCI Authentication and Session Management, under WCCONFIG Web Authentication Options, a checkbox is available:

The Web authentication method can be DIGEST-based or COOKIE-based but not both. Cookie-auth allows for better control of the web login pages using form based authentication. Digest-auth forces the browser to popup a dialog which may not be desired.

The requirement for the PCI Session Management process to work correctly is for the user's browser to have cookies enabled. If the user has cookies are disabled in this browser, PCI Authenticaton and Session management will not work.

Idle Timeouts:

Idle session timeouts will force the web server to log off the user. The web server idle timeout is defined under WCCONFIG | General Settings | Idle Timeouts.

Under normal (non-PCI) Wildcat! operations, when the user is logged off due to an idle session, the user simply needs to refresh his page for automatic re-login. This automatic re-login behavior was manifested due to the HTTP BASIC/DIGEST authentication standard which has no "logoff" concept and no browser or http client requirement to release user credentials.

Under PCI operations, the web server will invalidate the old credentials and force the user to re-login. The purpose is to secure the user machine when the user walks away for an extended period (i.e. lunch, meeting). However, for users that are interrupted (i.e. get a phone call), the requirement to re-login might be an annoying inconvenience.

You can manage this situation by either increasing the idle timeout time or disable idle timeout checking for the user security access profiles.

PCI Login Token Cache:

When PCI Session management is enabled, WcWEB will create and use a special file stored in the DATA folder called:

data\PciLoginTokens.Cache

This file is used to save the one time usage of login authorization NONCE values so that they can not be used again or replayed after the user is logged off.

The PCI login token cache file is not maintained by Wildcat!. This file can be deleted during maintenance periods manually or using a Wildcat! Event.

Strong User Password Storage Protection:

Some PCI auditors may ask how the user password is secured under Wildcat! The following information can be provided to the PCI auditors:

The user database is stored under the DATA\ sub-folder by default. The actual physical DATA location is defined under WCCONFIG | PATHS section.
The user database is exclusively opened and locked by the Wildcat! Server. No other process can access the database while the Wildcat! Server is running.
The encryption algorithm used to protect user passwords is one of the industry tested and accepted algorithms referenced in the PCI DSS glossary.

Please note, the exact hash and encryption scheme used in Wildcat! is a legal SSI trade secret and can not be exposed without a signed NDA. This security policy helps minimize the risk to customers and our product line.