

ASK HN: Best practices for storing Credit Card information - ninjaa

We run a hosted e-commerce app, and currently store credit card numbers, expirations and cvv2s as plaintext in the DB.<p>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?<p>Please advise as I am ready to make this change yesterday. We do need to store the numbers somewhere for repeat customers ...
======
olefoo
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

~~~
netcan
_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?

~~~
Jasber
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...](http://en.wikipedia.org/wiki/Card_Security_Code#CVV2_limitations):

 _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._

~~~
there
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.

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

[https://www.pcisecuritystandards.org/security_standards/pci_...](https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml)

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.

------
oldgregg
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.

------
there
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.

------
agotterer
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.

------
jonknee
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...](http://www.authorize.net/solutions/merchantsolutions/merchantservices/cim/)

------
umangjaipuria
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?

------
noodle
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.

~~~
tptacek
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_.

~~~
noodle
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.

------
multifarious
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.)

------
vaksel
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.

------
jcapote
Simple. Don't.

