Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'll be making a website with a membership type of option for the website, and I'll be most likely using Authorize.Net to make the transactions, however, I need to know what kind of encryption I can use to store credit card numbers in a MySQL database?

share|improve this question

migrated from Jan 13 '12 at 13:20

This question came from our site for professional and enthusiast programmers.

If you have to ask this question, you probably shouldn't be storing credit card numbers. Outsource this if at all possible. – Cody Gray Jan 13 '12 at 12:44
If you can't properly handle them, why store them at all? Save them somehow during the transaction and then delete all data about them. Renewing membership is a bitch, but loosing all members because you failed to ensure that your security was proper is worse. – Zar Jan 13 '12 at 12:45
What country are you in ? – ManseUK Jan 13 '12 at 12:46
@ManseUK - What does it matter what country he is in? Storing the credit cards is the same problem in any country – Ramhound Jan 13 '12 at 19:38
>"If you have to ask this question" even if you didn't, if the option to load PCI-DSS on someone else is available, take it. – StrangeWill Jan 13 '12 at 22:09

Why even store it in a MySQL database when you can be using Authorize.Net's Customer Information Manager API and taking PCI compliance and security issues right out of your hands completely and letting them do all of the heaving lifting for you? CIM let's you create customer payment profiles by storing the customer's credit card information on their end and then charging against that profile at a future date whenever you need to simply by referring to the payment profile ID at the time of the transaction.

share|improve this answer

The key regulation you must follow is the Payment Card Industry Data Security Standard (PCI DSS) and of specific interest here is section 3.4 -

Protect Stored Cardholder Data

Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

  • One-way hashes based on strong cryptography (hash must be of the entire PAN)
  • Truncation (hashing cannot be used to replace the truncated segment of PAN)
  • Index tokens and pads (pads must be securely stored)
  • Strong cryptography with associated key-management processes and procedures

The rest of section 3 is also worth reading in depth!

share|improve this answer
As pointed out above, the bottom line from that is that you don't want to have to follow PCI-DSS if you don't have to. Definitely better off outsourced. – Jordan Jan 15 '12 at 6:52

It probably (see note below) satisfies the requirements if you use a well-known symmetric cipher (such as AES or blowfish/twofish) on the sensitive data using a key stored someplace not accessible from the database. Since the result is non-printable, you can either hex or base64 encode the result for storage.

Obviously any system that does automatic encryption and decryption is going to be inherently less secure than a manual system, as the keys will have to be stored right there on the server for the thing to work. But the more you can separate them, the better.

Better yet, many gateway providers allow for mechanisms where you do not have to store the customer's card on your server, including's CIM and Paypal's Reference Transactions just to name a couple of examples.

Note: This does not constitute legal or security advice and should not be interpreted as such. You should always hire a local security professional if you have questions or concerns.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.