ASK HN: Best practices for storing Credit Card information | Hacker News Reader

ASK HN: Best practices for storing Credit Card information

10 pointsninjaa20 comments

We run a hosted e-commerce app, and currently store credit card numbers, expirations and cvv2s as plaintext in the DB.

Questions for the community: 1. Is this a crime or criminal negligence? It should be ... 2. What are the best practices for storing credit card data in a secure, PII safe fashion? One way hashes? Last four only? Use some kind of vault service?

Please advise as I am ready to make this change yesterday. We do need to store the numbers somewhere for repeat customers ...

View on HN

If you are processing credit card payments you are supposed to adhere to the PCI-DSS standards which do include encrypting Cardholder Data goto https://www.pcisecuritystandards.org/

Get the self-assessment questionnaire and work through it.

Encrypting columns, rows or tables in your database is trivial, pgcrypto will do this for you if have postgres. Or you can hack something together w/ http://php.net/openssl pretty easily. Whatever you do, don't try to write your own encryption routines, people will laugh at you and Moldovan teenagers will buy BMWs with your customers money.

Set up views so that non-finance personnel see the last four digits only, and those with a need to know can see the full PAN and have their accesses logged to an audit table that cannot be altered without superuser privileges.

Right now you can slide by, but in a few years your payment gateways and merchant banks are going to be insisting that even small processors have outside audits.

And according to the standard you should never store the cvv2 code, you should request it each time.

HTH

And according to the standard you should never store the cvv2 code, you should request it each time.

How are you supposed to take recurring payments?

I believe you ask for it the first time. Once its approved once you can assume they have the physical card.

But yes, you are not supposed to store the CVV2. Via http://en.wikipedia.org/wiki/Card_Security_Code#CVV2_limitat...:

Since the CVV2 may not be stored by the merchant for any length of time[2] (after the original transaction in which the CVV2 was quoted and then authorized and completed), a merchant who needs to regularly bill a card for a regular subscription would not be able to provide the code after the initial transaction.

you can also process transactions without a cvv. credit card companies just charge you (the vendor) more for these transactions, just like those without verified addresses and cards entered by hand versus those swiped through a reader.

Some payment gateways support subscription billing trustcommerce.com had this feature.

good post, I'd add a small often overlooked point is that you should be very careful with your backups and your encryption keys.

All the major card companies banded together and formed a standards group:

https://www.pcisecuritystandards.org/security_standards/pci_...

Once you reach a certain volume of transactions you are required to comply. Doing so now is probably not feasible if you're small, but you can still take the spirit of the standard and do your best.

Credit card storage is scary. I was working with a company that had 20k credit cards stolen. Visa never called, nobody was notified, nobody ever found out. Only a small handful of customers who had just placed orders even suspected who it was. We actually tried to notify the merchant and credit card companies and they were like "huh?"

They don't store credit cards anymore.

you are definitely not supposed to be storing cvv numbers, in plaintext or otherwise. according to pci, you're not supposed to be storing or processing credit card numbers on the same machine (or even network, i believe) as your public web server.

if you are not sure how to handle this stuff, please, for the sake of your customers, use a company that does know how to do it. companies like braintree (http://www.braintreepaymentsolutions.com/) have a secure vault service that lets you store credit card information on their servers which you then access on a per-charge basis using a token.

I'm a developer for a large e-commerce site. We require users to input their credit card for each purchase (no save functionality). We store the credit card for the duration of the transaction. Which is usually a few seconds. The time it takes to do run an AUTH ONLY. During these few seconds cards are stored with 256bit encryption on a server not accessible by a public IP. We use the mcrypt library in PHP.

I understand you want to save the cards for future purchases, but you should definitely give customers the option to input their card every time if they so desire. If you dont need the card in the future, theres no reason to save it. Most processing gateways will return a transaction id which you can use to take processing actions in the future. You can run voids, refunds or settle payment. For our site we settle payment once we ship the goods and its all done with transaction IDs. The only thing we hang on to is the last 4 digits of the card number as a reference.

If you are going to store the card numbers use a good, well known encryption algorithm. Hashing isnt encryption, plus a one way hash will not work since you wont be able to recover the number to process.

Its important you become PCI compliant, especially if you are selling a hosted solutions to other businesses.

Don't. Use a gateway that can do this for you. Authorize.net does this pretty easily. The API is called Customer Information Manager and you can store not only CC, but billing info. Makes it easy to do lots of advanced stuff (it's a good option for recurring billing when you want lots of control).

http://www.authorize.net/solutions/merchantsolutions/merchan...

Like everyone else is saying, don't. It's a lot of responsibility and that's not your main business anyway. How about using something like Amazon FPS instead?

1) i don't believe that the act of storing the information in plaintext is illegal, but it could contribute to negligence suits if you mess up.

2) 2- or 3-TDES (http://en.wikipedia.org/wiki/Triple_DES) encryption; fully secure & restrict access to whatever database you use and whatever system holds the database; SSL connection (obviously).

having said all of that, is there a reason why you're not using something like paypal, amazon FPS or some other payment service? they kind of take the work out of this stuff by providing a secure way of accepting payments, including recurring stuff with stored CC#s.

we do paypal checkout and google checkout as well ...

you can do recurring payments in paypal.

If you have to type the name of an encryption algorithm into your code (and really, triple DES? what year is it?), you're doing it wrong.

TDES is old, but its still widely used specifically in the online payments sector. i mentioned it specifically because there's probably some existing solutions to be found.

i'm definitely not an expert, though, and the question was better addressed by someone else.

As everyone else has said, this is not a good situation. You don't want the overhead and risk of providing software security let along physical security for the storage of personal information unless your business model depends on shaving the fractions of a percent that it may save you in processing.

In all seriousness, get set up with a major processor and get on with your business. (PayFlowPro would work well for the recurring payments you seem to need as a feature.)

Our cc processor has a vault for storing cc info, so this stuff is never on our servers, so we don't need to comply with anything. Check with your cc processor they might offer a service like that too.

Simple. Don't.

Reply on news.ycombinator.com