http://www.perlmonks.org?node_id=307038


in reply to Re: Re: (OT) SSL Certificates: Self-Signing and Alternative Solutions
in thread (OT) SSL Certificates: Self-Signing and Alternative Solutions

I'm always amazed by how many people think that it really is necessary to store credit card numbers on a system exposed to the net in the first place. Storing unencrypted cc numbers in a database without being *very* careful is just plain dumb.

First, why does no one ever figure out if they ever need to know someone's credit card number again? A while back I wrote a transaction processing program for a non-profit -- the system only ever handles the full credit card number in memory during the course of the transaction authorisation. The log and database only ever store a checksum of the credit card. So it's not hard to demonstrate that the card number was used, but anyone else breaking into the system would end up with a lot of useless checksums (assuming that we've done our checksumming correctly).

It seems to me that you could envision a similar system working even where you *do* need to know the number on a repeated basis...

Two databases are established. One allows read/write/update access to scripts running on the web servier. The other only permits insert/write-only access to the same set of scripts.

The first time a customer places an order data is written to both systems. However, the db with read/update capability only stores a checksum of the card used. The second system stores the actual number (not ideal, but you could combine this with a public/private key infrastructure as well if you were really paranoid).

Future transactions would verify that the checksum was valid in the local database before transmitting the order to the second system for actual processing (which would need the real cc number).

You'd end up with a fairly robust system that could withstand several types of compromise fairly well... I think. Anyone want to poke holes in this?

  • Comment on Re: Re: Re: (OT) SSL Certificates: Self-Signing and Alternative Solutions

Replies are listed 'Best First'.
Re^4: (OT) SSL Certificates: Self-Signing and Alternative Solutions
by hardburn (Abbot) on Nov 14, 2003 at 14:41 UTC

    Most attacks are going to be against the database server itself, not the scripts. So I'm not sure what the privilige seperation buys you in this case. If the CCs aren't encrypted in your database, they're vulnerable.

    Personally, I never want my CC to stick around in someone else's database, except for my bank, and only then because they must have it. Amazon's "One-click Shopping" isn't just a dumb patent, it's a dumb idea to begin with. Really, is it such a big inconvience to type your CC number back in? Considering the security you gain by not saving your CC num, it's a very small price to pay.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated