in reply to Encrypting Credit card numbers

If you want to protect sensitive information in the database, don't allow the web server to communicate directly with the database server.

This has a couple of implications:

The intermediary is an "application server", and is either housed on its own box (a "three tier" configuration), or it's colocated with the database. (Big players go three tier, with firewalls between each tier).

Writing a simple application server is actually pretty easy. Code for accepting socket connections is widely available, so that part shouldn't be too difficult. (Lincoln Stein's Network Programming with Perl is a great reference.) Accessing the database is also pretty easy.

The trickier part is in designing the protocol. A simple way to start is to look at your existing queries in terms of inputs and outputs, and to wrap each query up inside of a "command" that the web server will then send to the application server. If you use XML to express the inputs and outputs, you're on the road to XML-RPC or SOAP.

If you get this far, and assuming that your application protocol doesn't include something like getAllCreditCardNumbers(), then the credit card data as a whole is probably safe, though encrypting it in the database might help you sleep at night.

Replies are listed 'Best First'.
Re: (dws)Re: Encrypting Credit card numbers
by petethered (Pilgrim) on Apr 22, 2001 at 04:48 UTC
    Hmm... this is an intresting solution if the credit card number never gets passed back to the webserver or the intermediate server.

    Inital Process:

    1. CC number gets sent to DB server and gets returned a "key" to reference it for storage in the noncritical database.
    2. Uses said reference "key" to request that the card be processed.
    3. Intermediate server sends request to CC storage server who then processes the card and sends the request code to intermediate server who sends to webserver.

    Rebill Process:

    1. Billing software sends "key" to intermediate server with a price to be billed.
    2. intermediate server relays request to database server who then processes card and sends response code back
    3. Intermediate server returns status code to webserver

    I dont see any real problems in this process. Credit cards go in but they dont come out.

    Intresting solution.

    Pete

    insert into pete values('red hair','near green eyes','overinflated ego');