Best Practices
1. Cardholder Privacy - Full credit card numbers should never be stored in plain text. Ensure that your terminal is truncating card numbers and only showing the last four digits on receipts. Additionally, Visa® and MasterCard® regulations prohibit merchants from recording personal information on the sales receipt/draft. This information in conjunction with the account numbers listed on the sales draft could be used to commit fraud. Keep cardholder account and personal information separate and under tight security. Release of this information is only permitted to Graphite Payments or authorized law enforcement officials. It is extremely critical that CVV2 card validation numbers are not written, recorded or stored electronically nor manually under any circumstances. Also, credit card numbers or cardholder account information should never be transmitted via email or unsecured gateways.
3. Ensure Your Website Is Secure - If you have an e-Commerce website, IP terminal or POS system, complete the complimentary system scan available on this site.
4. Use Compliant Equipment - If you are using an older credit card terminal, check with Graphite Technical Support to make sure it is compliant with the new regulations. Any terminals recently deployed from Graphite Payments should be fully compliant.
5. Do Not Log PIN Blocks - Although PINs are protected in an encrypted or enciphered form within a transaction message, they must not be retained in transaction journals or logs subsequent to PIN transaction processing. Many processing environments have programs that actively overwrite or mask PIN blocks; however, any processor of PIN-based transactions must evaluate all inbound and outbound PIN-based messages to ensure there is no systematic logging of PIN blocks within any systems. In addition, any temporary logging function for transaction research or troubleshooting must include the active removal of PIN blocks. This requirement helps prevent harvesting and subsequent attacking of any large repository of logged encrypted PINs.
6. Always Maintain Secure Key Loading Procedures - When POS PEDs and host security modules are first initialized, they must be securely loaded with encryption keys. Regardless of the type of tamper-resistant security modules being initialized, the principals of split knowledge and dual control must be in place at all times to maintain the secrecy of the key being entered. In addition, merchants must have established procedures that prohibit any one person from having access to all components of a single encryption key.
7. Only Use Keys for a Single Purpose – To limit the magnitude of exposure should any key be compromised, encryption keys must be used only for their intended purpose. This applies to all keys used in POS PED and network processor links. Production keys must never be shared or substituted within an entity’s test system. All master keys or hierarchy keys used in any production or test environment must be unique and separate for each environment. Use of any production key in a test system is a high-risk violation. Any production key exposed in the test system or any key that has been encrypted using such exposed keys should be considered compromised and be replaced.
8. Ensure All Devices Have Unique Keys – Cryptographic keys resident within a PED must be unique to that device. This includes initialization keys (often called A and B keys), key-exchange keys (often called communication keys), and PIN-encryption keys. By ensuring that these keys are unique to each device, a merchant can make sure their PEDs are unattractive targets for an attack. This is because a unique key that has been “cracked” exposes only those PINs that were actually entered at the particular device attacked. Conversely, compromise of a key used for a large number of devices could expose all PINs entered at all of those devices. When validating compliance with this requirement, technical staff should also look for weak keys (known as default, predictable, or simple keys).