Re: Witango-Talk: Encrypting Credit Card Info within the Database

[Robert Sfeir]

You know for what it's worth, I use a Blowfish encryption mechanism which allows encrypt / decrypt at 448bits using a secret key which can be related on a per user basis.

You can go to Acme.com and download the library there. It's a java bean, and from that you can do encrypt decrypt. It's free. If you're in the US, I have a bean which will work with Tango to do that. If you're interested, write me off list.

R

On Tuesday, October 22, 2002, at 10:04 AM, Scott Cadillac wrote:

I store only part of the Credit Card numbers with the first and last 4
digits:

4501....1516

This helps to resolve any reconciliation issues when the customer or vendor
own more than one Credit Card.

Hope this helps. Cheers...


----- Original Message -----
From: "Garth Penglase" <[EMAIL PROTECTED]>
To: "Multiple recipients of list witango-talk" <[EMAIL PROTECTED]>
Sent: Tuesday, October 22, 2002 6:47 AM
Subject: Re: Witango-Talk: Encrypting Credit Card Info within the Database

Yeah, I agree, and also it is a real hassle dealing with a lot of
different companies on the net who persist in keeping my credit card
details and using them for re-orders when i'd much rather have them
email me an invoice with a direct link to submit whichever card I
want to use again. Some of these companies force me to store credit
card details with them if I want to use their services and while I
have been lucky so far I am not naive enough to believe that they are
totally secure.

I would much prefer that the standard on the net was to re-enter cc
details each time.
Garth

I don't store credit card numbers at all. If the client is a repeat
customer, I request that they key in their credit card again. I
thought at first I would get a lot of flack for this, but as it
turns out, the client is actually more comfortable knowing that the
number is not stored anywhere on our servers. I even tout this fact
as a selling point. What better way to attract criminal activity and
hackers then to have a database filled with good credit card numbers.

Just my $0.02

Why not just install PGP and use the command line to encrypt and

decrpyt

the data? I've done this from within Witango for transmitting sensative
data through the internet.

Robert Shubert
www.witangostore.com

"Fogelson, Steve" wrote:

Thanks for the responses.

Eric,

I looked a little more at the Shopzone's code. They store the key as

a file

within the web site. Probably not good. If the db's are available to

the

 hacker, so would the key. The contents of a sample key seem pretty

simple:

BT_GK1=RHDDzwEAAAACQAAAANpYPBbZhSKJ0OSvdW9MypLdS+UzuAT7D+2U75yKRAPtV 0ZQ0

2mZ2

ynXdidrotPUEuIY9N0eCEz22AA+fEd06DNAAAAAlu1KX7S2vKW0PNpdagJS/ WQ0sXFVvgPw2

tfZq

 OZIeO9xzkjL1zaALW6NWVPsKP7Hf53nTNjRAHj0V9ixa2qWcgAA

BT_GK2=RHDp9wEAAAACQAAAANpYPBbZhSKJ0OSvdW9MypLdS+UzuAT7D+2U75yKRAPtV 0ZQ0

2mZ2

ynXdidrotPUEuIY9N0eCEz22AA+fEd06DNAAAAAUX6yYYqMIIKCVTJ71ZoYMoJVMnvVm hgyg

lUye

 9WaGDKy7lDyX0u9HT1znlxNyL/O3hUkNXwWpGRYJpj/QCHGKQAA

 I don't know anything about encryption, but the code kind of

indicates a

password protected public and a private key.

I'm not trying to disseminate any proprietary info for ShopZone. If

I am

 crossing the line, someone let me know right away. I am simply

intrigued by

 their "site owner" key generation and was wondering if anyone has

any

 suggestions for something outside of Witango that would work
within Witango.

 Maybe this would be a consideration for future enhancement to

Witango. It

 would be a nice feature to be able to securely store info in
fields of db's.

 Thanks
 Steve

 -----Original Message-----
 From: Eric Weidl [mailto:ejw@;intersites.com]
 Sent: Monday, October 21, 2002 3:54 PM
 To: Multiple recipients of list witango-talk
 Subject: Re: Witango-Talk: Encrypting Credit Card Info within the
 Database

 Hi,

Has anyone done this in the shipping cart software an databases?

 Yes.

In their software, you create your own "key" by moving the cursor

all over

the screen. I suppose some sort of random character generation.

This unique

"key" is used to encrypt and decrypt the cc info.

 Sounds cool.

As I have mentioned before, I am writing my own Witango Store. For
additional security, I would like to encrypt the cc info fields

within the

database. I don't expect that someone would hack my sites, but you

never

know.
I looked at the Witango <@CIPHER> metatag. it states BitRoll,

Caesar, and

Rot13 are not secure at all, and OneTimePad is only as secure as

the keys

are managed and generated.

 BitRoll, Caesar, and Rot13 are trivial and should be avoided for

this

 purpose. It would take a hacker only minutes to break them

 OneTimePad is, in theory, the only 100% secure classic encryption

method.

Unfortunately, practical issues prevent it from being truly secure.

The name "OneTimePad" refers to the theoretical design of using an
encryption key once and only once. The theory is that each party to

the

 encryption would have a book or "pad" of papers. Each paper would

have a

 different, unique encryption key written on it. Each time you want

to

 encrypt a message (e.g. a credit card number), you would take the

top sheet

 from the pad, use it to encrypt the message, then throw the page

away. The

person receiving the message would take the top sheet from the book

(which

 should match the sheet you used), and would use it to decrypt the

message.

To demonstrate the issues (and flaws) with the OneTimePad cipher in

the

real world, let's apply it to your situation.

Think of your "submit order" and "review orders" Tango applications

as the

two players in the encryption game. To start, your application gets

a CC

 number from a user. Your "submit order" application should encrypt

that

 message with a unique key and then store it in the database, where

the

 "review order" application can later retrieve it.

 Okay, so the submit order TAF has to encrypt the number and to do

that it

 needs a key. Where does it get the key? It could make one up, but

then it

 would have to pass that key to the review orders TAF so it would

know the

 key. How is it going to do that? You could store your keys in the

database,

 but that's not very secure, is it? You could store the keys in a

file on

 the server, but if a hacker can get to your database, they can

probably get

 to anything on the computer.

 Even if you found a secure place to store the keys, you would have

the

 additional problem of having to remember which key was used to

encrypt

which credit card. Every scenario I've seen for solving that problem

is

unsecure. Keep in mind that to meet its theoretical limit, each key

in a

 OneTimePad solution should be used only one time! That means your

review

 order TAF could display the un-encrypted CC number once, but then,

in

 theory, it should throw the key away. Not exactly user friendly.

 This summary is a long winded way of saying there is no very good,

complete

way of encrypting data in a reversible fashion using Tango's CIPHER

meta

 tag. It could be part of another solution, but I don't think it

could stand

by itself.

Like anything, security is a continuum, and only you know where your
threshold is on that spectrum.

Another option you might look at are digital certificates.

Finally, I'd be very curious to see an explanation of how Shopzone

stores

the key you say they generate. I understand that they are probably
generating a random key based upon the movements of your mouse over

an area

 of the screen, but they still have to store that key somewhere.

 Hope this helps.

 Eric

_______________________________________________________________________ _

 TO UNSUBSCRIBE: send a plain text/US ASCII email to

[EMAIL PROTECTED]

                 with unsubscribe witango-talk in the message body

_______________________________________________________________________ _

 TO UNSUBSCRIBE: send a plain text/US ASCII email to

[EMAIL PROTECTED]

                 with unsubscribe witango-talk in the message body

_____________________________________________________________________ ___

TO UNSUBSCRIBE: send a plain text/US ASCII email to

[EMAIL PROTECTED]

                with unsubscribe witango-talk in the message body

--
_____________________________________________________________________ ___
TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
with unsubscribe witango-talk in the message body

--
______________________________________________________________________ __
TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
with unsubscribe witango-talk in the message body

_______________________________________________________________________ _
TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
with unsubscribe witango-talk in the message body

________________________________________________________________________
TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
               with unsubscribe witango-talk in the message body