Ask HN: Storing Credit Card Numbers

The first issue is why do you want to store them, just for the record or do you need to do something with them. Do you need to store that actual number or would a hash of the number be acceptable (for comparison purposes).<p>Databases are commonly compromised by SQL injection attacks that reveal the contents of the database. Some databases, MySQL for example, have functions that allow the database to display the contents of files off the filesystem. But on the whole, if someone has gained access to your database it does not immediately follow that they have access to your code. Only that you need to tighten up on security.<p>An alternative to hashes, but somewhat more expensive computationally, would be to encrypt the CC number into the database using the public key of a Public/Private encryption scheme (PGP for example). So even if they got hold of your database and the public key they could still not, realistically, decode the CC number. Providing the private key is held securely on another server!<p>It all comes down to what you need to do with the CC numbers. Long ago I worked on some software to track CC fraud for a major store (was a CC number used in store A also being used in store B, it was likely that the card had been cloned as most customers only shopped at their local branch), we used hashes of the numbers. We didn't even need to know who the customer was, everything was driven by electronic till receipts and hashed CC number.<p>Do you need the actual CC numbers or would a hash be equally as usable?

Quite a few people suggested gpg/hash or public key. If you do that (I wouldn't), be sure to include fluff before and after the number inside your signed message; A credit card has ~30 bit of randomness, and if you know the hashed/encrypted (even if salted) version of the hash, a hacker can just enumerate the credit card number to see if it comes out the same.<p>It's not just the credit card numbers that are valuable -- it's the combination of credit card number + billing address that are generally required to make a purchase. 30 bit enumeration can require just a few minutes (or even seconds) on modern CPUs and GPUs. So, if you do store them this way, fluff them front and back with random data that you ignore when decoding.<p>What would I do? Make sure the user has a password (Use HMAC/bcrypt to verify password; DO NOT STORE PASSWORD!); When the user logs in, derive key from password using a different HMAC with different salt, and store in memory/session vars only for as long as needed. Use <i>that</i> key to encrypt the credit card number with a symmetric cipher, e.g. AES; make sure to purge these keys from memory/session directory early and often.<p>Advantage: You don't have access to the credit card on record even if you (or a rogue employee) wants to. Active participation from user _required_ to get access to data. If your server is hacked, only credit cards used while a hacker has complete view of traffic are compromised, and not all data stored.<p>Even better: offload to payment processor and make it their problem.<p>Really.

You should be using a separate database server than your web server if you're going to be storing credit card numbers. The database server should not be accessible by any machine except a small whitelist of IPs that you've specified. That way when your webserver gets compromised, it will require some looking around to realize the database containing credit card numbers isn't there.<p>Most server compromises that I've seen have stayed local to the server - I'm not a security pro; but generally I've seen the server that got knocked over get messed around with, anything on that server was fair game.<p>Beyond that, I'm sure there are other things you should do to protect the database that contains the credit card numbers; but seriously - keep them off your web server.

I'd recommend starting with the PCI DSS. That standard is required by pretty much all card companies, and compliance is enforced by a self-assessment checklist and/or security assessor. If you plan on storing card information, you must be in compliance with this standard.<p>PCI DSS Standard: <a href="https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml" rel="nofollow">https://www.pcisecuritystandards.org/security_standards/pci_...</a><p>More info on Wikipedia: <a href="http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard" rel="nofollow">http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu...</a>

You should look up what is recommended by the PCI DSS (<a href="http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard" rel="nofollow">http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu...</a> / <a href="https://www.pcisecuritystandards.org/" rel="nofollow">https://www.pcisecuritystandards.org/</a>).

Let your payment gateway handle it. Just store the reference number they give you in your database, and look it up in their web interface later if you need it.<p>Don't let the number even touch the disk!

If you're going to store that info, use gpg (or perhaps gpgme) to encrypt it and keep the private key for decryption somewhere completely separate. Access to the source code shouldn't matter at all.