[thelist] how secure to store credit cards

[.jeff]

keith,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Keith
>
> Hey thanks jeff for the details on Cold Fusion's Encrypt
> function!
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

you're welcome.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > coldfusion's Encrypt() function takes a string and a
> > key.  it uses the key to encrypt the string --
>
> I'm assuming that the same key is needed to unencrypt
> the string. If so then Erik's earlier worries would be
> valid, keeping the key on the server would make the
> attempt quite bogus. Unless.... unless you don't keep
> the key on the server.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

yes, you need the same key to decrypt the encrypted string.  you *have* to
keep the key on the server somehow to use when you call the Encrypt()
function.  for use in the Decrypt() function you could request the key from
the administrative user, but that only solves half the problem.  the other
half is that damn Encrypt() function.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Would this work as a poorman's method (considering the
> $400 price tag for integrating PGP with CF)? Instead of
> keeping one key for all transactions, generate a unique
> key for each transaction and email the key and
> transaction number pair to the merchant during the
> process. A bandit would have to snag each email (or
> break into the email server) plus break into the
> e-commerce server to have an open door.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

this would be one method.  as you say, it would be fairly difficult to crack
as you'd have multiple channels you'd have to monitor to grab the info for
each and every transaction.  however, since it's a reversible encryption
algorithm, if someone were to get their hands on the database full of
encrypted credit card numbers, there's nothing to keep them from trying to
find the key through manual techniques.  of course, if they manage to get
the database, they probably can get the source code which will give them a
clue as to how the key is created and that it's unique for each record.
however, except for all but the most determined, this will probably suffice.
to truly cover yourself, you've gotta get the numbers off the web-accessible
machine.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> I've seen a variation of a two-way hash one-key
> encryption done in perl. That installation used only one
> key for all transactions but the key did not exist on
> the server in hard form, it was kept in memory using
> mod_perl. (once a routine has been put into mod_perl
> memory you can remove the physical script and still
> run it, until you reboot). Question, does CF have any
> comparable capability for placing a value or routine in
> memory for persistent use?
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

sure, there are application and server scopes you can put persistent data
into.  what's to keep the person that gains unauthorized access to the box
from putting a template on the box that simply outputs the variable value,
giving away the key?

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > it's alittle spendy ($400), but the expense is worth
> > it for the peace of mind it'll give you.
>
> Wow, that is a bit expensive, considering that all the
> PGP tools are free and take less than an hour to have
> running with Perl.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

careful with the "all the pgp tools are free" statement.  alot of pgp
utilities have commercial use clauses that have price tags associated with
them.

i'm guessing that most of the cost with the cfx_pgp custom tag is the
hardware you get with it (a small device you plug into a parallel or usb
port).

thanks,

.jeff

http://evolt.org/
jeff at members.evolt.org
http://members.evolt.org/jeff/