Fog Creek Software
Discussion Board

Storing credit cards in databases

What is the most secure way to store credit card details in a web application between the time an order is placed to the time it is fulfilled?

I am building an application like Yahoo store to allow store owners to create their own online shops.

Initially the store owners will process the orders offline, using the credit card terminals in their shop.

When a customer enters their credit card details they will be encoded and inserted into MySQL. The shop owner will receive an email with a link to a password protected web page displaying the credit card info. All this will be over SSL.

Once an order is fulfilled my application will remove all but the last 4 digits of the credit card from the database. This is to reduce the amount of card details stored, but to still have a simple audit trail.

I have thought about encoding the credit card details with one of MySQL's encode/decode functions, but that would require the server to store a password somewhere to enable decoding of the details. (

ecommerce guy
Monday, December 23, 2002`s not an answer to your question...but I`m a little suspicious about your e-commerce experience...
Store financial data in MySQL?! WOW:)
If you need a free database, consider using Interbase/Firebird, it`s slower but much more reliable.

>What is the most secure way to store credit card details in a web application between the time an order is placed to the time it is fulfilled?

And the answer to this question is:
Avoid the idea of storing credit card info. You`ll be the one who responsible, if this info will be stolen. Spend your time on finding the way to avoid this, not on finding the way to store info securely.

Monday, December 23, 2002

Hmmm. Although it would be nice to be able to avoid storing encrypted card details altogether, there are some situations where a vendor just has to. Essentially i'd say just go for the most reliable database you can (i'm not sure MySQL fits that) and implement some third party encryption method. 128bit key, whatever...

Andrew Cherry
Monday, December 23, 2002

I'm no security expert, but I'd recommend that you pick some well respected encryption algorithm, and I would also hash the encryption key against a key field or something that won't change in the record, to make sure that not all of the credit card numbers can be decrypted with a single key.  Use a cryptographic hash function for that.

Keith Wright
Monday, December 23, 2002

Yeah, right. MySQL will do just fine. I use it for several e-commerce applications and have no problems. It's fast, stable, and does what I need.

Of course, I'm not doing millions of transactions per second, and never will.

Monday, December 23, 2002

Put your credit card database on a server in a bunker style data centre (with 7/24 physical security) and don't connect it to the web.  Ok, maybe a little extreme, but work backwards from there.  Just my 2 cents.

Monday, December 23, 2002

For the sake of all that's holy, don't go anywhere *near* storing credit card numbers unless you're an national/international-level expert in financial security systems.  That's just begging for a lawsuit when it all inevitably goes horribly wrong. 

Make it easy for your clients to integrate the likes of Netbanx ( or Worldpay ( into their transactions.  Some of these companies will offer discounts on integration fees if the shopping software has been designed to their standards - this makes a good selling point for your software.

This pushes transaction fees a little higher, but the automation and security are well worth it.  There are generally discounts for people who already have merchant accounts, and some providers will supply merchant accounts to people who wouldn't normally qualify for them in the offline world (Netbanx certainly used to).

Monday, December 23, 2002

I'd say MySQL is OK, but use the Inno base tables that support FK's, transactions, and referential integrity.  Doing this with MyIsam is probably a little risky. 

Otherwise, I agree with everyone else and say don't do it in the first place.

But if you have too, then ...

1) Don't use the standard mysql port.

2) You had better have a firewall. This seems like a no brainer, but you would be suprised at the number of people running their web servers wide open. Their MySQL ports exposed to the world.

3) Use intrusion detection.

4) Put your db on a different network. In other words, have a network for all web traffic, then have the web servers communicate to the dbs on yet a different network. This helps reduce network congestion and adds another network layer that a hacker must first indentify then fight through.

5) If you have control of your routers the way we do, don't telnet into it from outside of your network. Also check it periodically to see that it has't been coopted.

6) If you need access to your business db across the local area network, do it using a secure socket. If someone has broken into you network, they could easily snoop user name and password data.

7) Make sure that the db server is very particular about who it allows to connect and from where. Dont just give all of your servers a single user name and pass that can connect from anywhere in the galaxy.

8) Hash or encrypt sensitive data before it's sent to the db. Otherwise, it's moving in clear text across the network and can be snooped.

9) Log and pay attention to events.

10) Rigorously check session data. What if someone attempts to hijack a session? Does you session handling take this for granted? Allow sessions to continue ONLY as long as they are returning from the same IP, platform, and OS.  (I don't know about some languages, but it's easy to get this info in PHP).  If a session that started on a Mac box comes back on a FreeBSD box, somethings up!

11) Make sure you firewall doen't bleed NetBios/SMB data.  May as well just shoot yourself otherwise.

I know some of the things on the list go beyond the application level, but I don't know how much you're responsible for in the first place.


Monday, December 23, 2002

I'm with JP on this one. If you have to ask about these things on JOS, please just get this out of your head and outsource this stuff. This definitely isn't Kansas anymore.

Just me (Sir to you)
Tuesday, December 24, 2002 ( ) offers a payment gateway as well.  You just ship the customer off to their gateway for processing the credit card info.  You don't have to store their info on your handles all of that.

I'd second the motion of going with a third-party gateway service for credit card processing. Why deal with it at all if you don't have to?

Tuesday, December 24, 2002

Several months ago we`ve built a payment proxy that  works with several payment gateways.
One of the problem is that direct access is offered by some of these gateways to the clients that have their own Merchant Account. Others may use the company`s account (some of payment companies offer the subaccount service -i.e. one can use their Merchant Account with help of subaccount created inside the payment company) but have limited access to the gateway.

Tuesday, December 24, 2002

*  Recent Topics

*  Fog Creek Home