Best practices to store CreditCard information into DataBase

Question

In my country the online payments are not an old thing, the first time i saw a web application taking payments directly to a local bank account was last year.

So, Im a newbie coding web payment system.

My question is, what are the best practices to store creditcard information into the database...

I have many ideas: encrypting the creditcard, database security restriction, etc.

What have you done?

Solution 1

DON'T DO IT

There is simply far too much risk involved, and you will typically need to be externally audited to ensure that you're complying with all the relevant local laws and security practises.

There are many third-party companies that do it for you that have already gone through all trouble of making sure their system is secure, that they comply with local laws and so on. An example in the US that I have used in the past is authorize.net. Some banks also have systems that you can hook into to store credit card data and process payments.

I realise the country you're in may not have as strict laws as the U.S., but in my opinion that's no excuse for rolling your own. When you're dealing with other people's money, the risk is just too much to warrant.

Solution 2

In 2020, use Stripe, and avoid storing payment information yourself.

HISTORICAL ANSWER:

For this, I recommend a comprehensive, layered approach.

First, storing credit card info should be an option.

Secondly, the data should be stored securely, using a strong form of encryption. I recommend AES with 256bit key size. Make sure when choosing your key, you use the entire keyspace (it's a rookie mistake to just use a randomly generated alphanumericsymbol string as a key).

Third, the AES key needs to be properly secured. Do not embed the value inside your code. If you are using windows, consider using DPAPI.

Fourth, you will want to setup database permissions so that applications and computers will have access on a need to know basis.

Fifth, secure the connection string to your database.

Sixth, ensure that any application that will have access to the credit card data, will properly secure it.

Solution 3

At miniumum follow the PA DSS (Payment Appliction Data Security Standard). More info can be found here:

https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml

Also it would be wise to look at PCI DSS, which could be found here:

https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

Solution 4

You should avoid storing any credit card information due to the risks to you and to customers of doing so.

Solution 5

Encrypt encrypt encrypt. Don't decrypt if you don't absolutely have to - don't decrypt to show the last 4 digits. Don't decrypt to tell the user what their card was.

In fact, if you can, don't even keep the encrypted card numbers in the same physical server as the rest of the user information.

View more solutions

Comments

[Garis M Suero]

Thanks, im also thinking to ask for the CVV2 (back three digits code) every time the logged user is going to pay for any product...

[dplass]

facepalm, I'm so dumb for not immediately thinking of this. You should definitely look at the PA DSS and PCI standards.

[Waleed Al-Balooshi]

@Garis another benefit of using the code is that some payment gateways will reduce the transaction few is you use it. At least the bank that we used had lower transaction costs when we switched to asking for the security code.

[ejfrancis]

I even thought saving creditcard numbers was illegal (Netherlands). So we obfuscated the numbers with ************ in the xml-transaction-logs.

[Cade Roux]

@Garis Suero The CVV2 codes are not allowed to be stored. When you get the CVV2 (and zipcode and other information) your rates will be lower. Often times there are several different rates you might be charged depending on whether it's a rewards card or not, etc.

[Garis M Suero]

I see, Im definitely not storing the cvv2 code, i will ask for it every time the user is asked to pay for some product... In other hands, i don't think my country have that kind of laws yet, i will investigate further and will let you know in few weeks...

[Garis M Suero]

The problem with this approach is that many of that sites have restricted my country as the credit card's country... im going deep with this situation and i will let you know if i can do it with your suggestion...

[Dean Harding]

@Garis: Yes, I understand it can be hard depending on your country. I would try asking around with some of the bigger banks, since some of them also provide an API for this kind of thing.

[PaulG]

AES doesnt have a 512 bit key size. (Rijndael maybe, but not the AES implementation).

[Alan]

You're right. the standard only specifies key sizes up to 256. However there is no practical limit to key sizes.

[joe snyder]

@Raju: the original number typically has to be retained to do subsequent voids, cancellations, refunds. eventually the allowed period for that would expire, and deletion would then be a good idea.

[Jason]

Do you know where a good place would be to store the key on a unix system? Since the encryption is only as good as the security around the key itself, I'm concerned how to protect that.

[NotMe]

@joesnyder: No it doesn't, and to my knowledge of working with CC transactions for over 12 years, it never has been necessary. All of that can be handled simply by knowing the transaction ID. Which is the only bit of information you should be storing.

[joe snyder]

@Chris: Our inhouse system's been using the MAPP protocol since 1995 and it definitely requires the number.

[Sumit Gupta]

-1 as it doesn't tell anything about govt. Ruling to store information, +1 for good techincal way.

[Ravinder Payal]

@Sumit gupta no one can tell you about laws of all countries and after all SO is not q/a for Advocates.