incrediBILL - 6:32 pm on May 1, 2013 (gmt 0)
First, chill, nobody is saying ""what are you stupid enough" or anything else, just pointing out there are often ways around it. Wish I knew your specific application as I've helped many sites side step CC storage.
I'm well aware of PCI compliance as I wrote a commercial ecommerce package that was on the market for 8 years, been there, done that. Implemented more payment gateways and worked with more payment processors than I'd like to admit. I've also watched site owners get into all sorts of trouble even when they were strictly in PCI compliance as Visa can get cranky and force you to put a $30K escrow account on your merchant account (or more) and they simply take that money out of your sales if you can't post the escrow funds directly.
I think you misunderstood my point in that if you plan to store them you must plan to use them, which means they must be decoded and I assumed that would happen on the server, meaning the script and code used to decode them would also be on the server which in the event the server gets hacked the hacker could use to also decode them therefore making the whole exercise of tweaking the encryption fruitless.
If you were using a CGI cart, something running compiled code, then I'd have a different opinion because the methods wouldn't be simply sitting there in script for the hacker to see.
If it's recurring billing, even that can be done without storing CCs.
If you must store CCs, I would keep them 100% separate from the member account and use some hashing scheme to relate the member account with the card number itself so that if a hacker downloads just your member data that they wouldn't get the card numbers. I would call the database something obscure like "profilebitmap" or something to throw them off the trail. Depending on the size of the client, I'd also consider doing what I did for one client which was separate the front end server from the databases altogether as the front end web server is usually the easiest to hack. If all they can do is mount and query the database from a backend server that has ZERO web access the odds of getting your database hacked are even less but not impossible.
BTW, be careful and don't leave CC data in sessions which is a common mistake many programmers make as harvesting session files can give someone a bunch of unencrypted cards in a hurry. I always pass the CC variables directly from SSL secured browser page to SSL secured browser page so it's only in the customer browser until they hit submit, then it's passed directly to the payment processor and discarded. Never stored on my server ever.
FWIW, our software used to just store them using standard SSL encryption with a different private key per website so even getting the key and hacking one site didn't allow them to decrypt all the sites and we never had a problem doing it that way. That's why I mentioned hackers dropping a line of script into the site to send the CC#s during the submit payment process as that's the only way they could get them without the private key to decrypt the card #s in admin.
Hope that helps and if you want some out of the box thinking on how to possibly avoid storing them, let me know more about the application as I know lots of different US payment processors that do some interesting stuff with APIs.