Re: Storing Credit Card Info? - Mailing list pgsql-general

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> ...storing credit card info in a database.
>
> Obviously, storing them in the clear is right out.  Do folks hash them
> with MD5?  Require a password?  If so, is there just one for all
> the credit cards?  A separate one for each?
>
> Big TIA for any hints, tips or pointers :)


A lot depends on exactly how you are going to use the information, but
the most important thing is not so much how to store the information but
how to restrict access to the database. The machine holding the database
should be well-isolated from other machines, and definitely not publicly
accessible. Making a hash would be good, except that a hash is one-way and
I am assuming you want to actually be able to extract the information
again. :) Basically, you need to defend against:

* Somebody breaking into the box that the database is on.

* Somebody breaking into the database that has the credit card numbers.

* Somebody breaking into the application box that does the actual work.

* Somebody sniffing the traffic between the two.

A secure connection (i.e. ssh, SSL) will take care of the last problem
above. Normal user permissions and basic security procedures take
care of the first one.

As far as someone with access to the database, you should encrypt the
credit card numbers, **without storing the decryption key in the
database or even on the same box**. This is fairly easy- the hard part is
securing the application box, because if someone manages to break into that,
it can be very hard for the database to distinguish legitimate requests from
false requests from someone who has broken in and is fishing for credit
card information.

(For this whole scenario, I am envisioning a web-based application that
remembers customer's credit card information for quick-n-easy ordering
of goods at a later time.. Your mileage may vary.)

A simple way to do this is to have the application be responsible
for encrypting and decrypting the information, and the database responsible
for storing it. This protects against somebody breaking into the database
server.

However, it fails to protect against someone breaking into the application
box and getting the encryption key and/or reading credit card numbers after
they are decrypted. Unfortunately, there is no simple way to defend against
this, besides the obvious securing of the box, because at some point the
application will need the credit card information "in the clear." You can
booby trap the box with tripwire and the like, as well as add some
rate-limiting and logic checks to the database box. For example,
equally spaced orders and/or alphabetically sorted users should sound an
alarm and halt the passing of information until someone manually
resets things. You could also set up some traps on the application side
that may catch the unwary intruder, such as deeply buried code that
adds an underscore to every username sent to the database box. A lack
of underscore would cause the database to slam shut instantly.

A better way is to have a third box (ordering) that is responsible for
actually placing orders. This way, someone breaking into the application
can only place false orders, but they cannot get at the credit card
information. Breaking into any two boxes will not get all the credit
card information either - they would have to break into all three.


*** Breakdown of a three box system:


** New customer:

* Customer enters information into web browser, send it to the the
  application box. Application box encrypts the information (unique key)
  and sends it to the ordering box, along with the decryption phrase,
  and the order details. It may even encrypt the passphrase so that only
  the ordering box can read it.

* The ordering box temporarily decrypts the information to place the order.
  If the customer wants their information saved, the ordering box encrypts
  the original message with it's own unique-per-user key, sends the
  doubly-encrypted information to the database box, and erases everything
  else.



** Returning customer:

* Customer places an order via the web browser, and sends it to the
  application box. The application box looks up the decryption
  phrase for that user, and sends the order information, the username,
  and the passphrase to the ordering box.
* The ordering box requests the information for that user from the
  database box. The database box sends it over.
* The ordering box decrypts it once with the key it has, and again
  with the passphrase it received. It places the order, deletes
  the information, and sends back a confirmation to the application
  box.

So the final answer to your question is: two separate passwords
for each credit card. Have fun and remember that all this complexity is
always worth it when it comes to protecting your customer's credit cards.


Greg Sabino Mullane greg@turnstep.com
Will consult for $$$
PGP Key: 0x14964AC8 200203131014

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iD8DBQE8j4D8vJuQZxSWSsgRAjN0AKD5fpFHNfoSgoNDkLjezl4Tk1mL4wCePWFF
FxBiy+z6b95v+sI7/AYlqL8=
=a52K
-----END PGP SIGNATURE-----