Re: [MacPerl] Safely Storing a Credit Card Number using Perl? -

[Brian McNett <brianmc@telebyte.net>]

>In article <21EA5C7735EFD1119BBF00104B321D5927DB76@DOGBERT>, "Aiken, Greg" 
><greg@tradesvc.com> writes:
>> I was hoping that someone in the group might be able to provide some insight
>> into this problem.  I will shortly be deploying a Perl based e-commerce web
>> based solution, whereby credit cards will be used to pay for products.  My
>> purchase app runs on a shared server environment (ie; multiple web sites &
>> developers, sharing same server).
>
>Hmm, do I smell an euphemism for "UNIX system" here ? :-)

Not necessarily.  My own website runs on a similar system, and it's 
Mac-based.

>> Given that Perl is source code readable, and that anyone on the server could
>> theoretically copy & read my programs, how does a Perl programmer securely
>> encode/encrypt a sensitive field so that others can't decode/un-encrypt the
>> sensitive field?
>
>One of the most important rules of cryptography is to have the security of 
>your
>system reside in the secrecy of your *password*, rather your *code*. This
>doesn't change in compiled code: If the collection of CC #s is big enough,
>you'll easily find people who go to the trouble of reverse engineering 
>assembly
>code.

Isn't there a PGP module for Perl?  Has this been ported/does it work 
with MacPerl?  It seems to me that what's needed here is a one-time pad.  
This means that a unique cryptographic key is generated with each 
transaction.  Someone might step in and break one key, but since that key 
is thrown away and never used again, it's worthless.  PGP can do this.

>To add to the security woes, if your environment is as open as you describe,
>you have to take into account the possibility of somebody attaching a 
>debugger
>to your server in mid-run. With a technique like this, it might even be
>possible to capture your password if you aren't careful.
>
>I wish I could offer you also constructive advice, but I'm not sufficiently
>familiar with e-commerce to do that.

The purchase app and the transaction software don't necessarily have to 
run on the same machine. In most cases it makes more since to out-source 
the transaction processing.

I haven't finished it yet, but my own solution involves FileMaker Pro and 
NetCloak.  Probably not perfect, but pretty good.

If I had the server all to myself, you can bet I'd do it with MacPerl 
(just staying on topic).

--Brian

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch