Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

(dws)Re: Encrypting Credit card numbers

by dws (Chancellor)
on Apr 22, 2001 at 03:10 UTC ( [id://74488] : note . print w/replies, xml ) Need Help??

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 database server needs to live on a separate box from the web server. If it doesn't, and the web server is hacked, all bets are off. Having the password encrypted in the database won't help you if the encryption algorithm and keys are exposed.
  • The database server must not accept connections from the web server box. If it does, and someone hacks the web server box, all bets are off.
  • The database box should not accept connections from the internet in general (with the possible exception of an SSH). Otherwise the database server is hackable, and all bets are off.
  • The web server communicates with the database server through an intermediary in a protocol that does not include raw SQL. Otherwise, the hacker can pass SQL through the intermediary, and all bets are off.

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.


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