Storing Credit Card Numbers

In general it’s highly recommended not to store credit card numbers in your application. But if there is a strong requirement to store credit card numbers then you would have to comply with PCI/DSS.

Here are some best practices/recommendations to manage credit card numbers in your application.

Data in encrypted format

1. In most of the cases Credit Card numbers are stored in Database. It should be fine to store it in the database as long as it’s not stored in clear format. Store them in the encrypted format.

2. Don’t ever log the Credit Card numbers in your log file. This is very critical. If it’s absolutely required to log, then log only last 4 digits of the credit card.

Encryption

1. Encrypt the Credit Card numbers in your mid-tier(Java virtual Machine or PHP ..).

2. Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 or SHA1. Note that the classification of a “strong” cryptographic algorithm can change over time. http://csrc.nist.gov/groups/STM/cavp/index.html

As of Sep’ 2013 – AES (128 bits or higher) is an acceptable encryption algorigthm. It passes PCI complaint.

Securing Encryption Key

1. It’s always adviced to keep the encryption key and the data in different locations (hosts). Since credit card number is going to reside in database, it’s recomended to place the encryption in a file system in your mid-tier.

2. File which houses the restricted key should have very restricted locked down permission settings. Access to the keys must be restricted to the smallest amount of users possible. This group of users will ideally be users who are highly trusted and trained to perform Key Custodian duties.

3. On a periodic basis change the location of the file which houses your Key.

4. On a periodic basis change the encryption key itself. When encryption key is changed then encrypted data should also be re-generated. Make sure to back up your original encrypted data before regenerating it.

Key Encrypting Key (KEK)

The keys themselves shouldn’t be stored in the clear but encrypted with a KEK (Key Encrypting Key). The KEK must not be stored in the same location as the encryption keys it is encrypting.

Encryption Key by Environment

Since there would be different environments such as: development, testing, staging and production. It’s recommend to have different encryption for each environment. Don’t ever share the encryption between environments.

Remediation Plan

Have a solid/complete remediation plan documented. In case if credit card numbers are compromised then this remediation plan should have to be executed right away.

Reference:

http://www.jtmelton.com/2012/11/24/year-of-security-for-java-week-47-store-encryption-keys-securely/
https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: