When your customer closes an order, delete the credit card number. This will make your site less attractive to serious hackers. Using some form of encryption should at least ward off the casual hacker. These methods won't eliminate 100% of the risks, but they will help minimize them.
If your customer is concerned about needing the number for future reference such as a misplaced order, they can simply print out the order page before the number is deleted. Then the responsibility shifts off your shoulders to theirs. Chris > Thanks for the responses. > > A few questions? > > What do you do with customers that don't want to use an online credit card > gateway? They don't want to debit credit cards until they know if items are > in stock and are ready to ship. Your first question is probably why don't > they maintain inventory on the site so availability is determined right away > and the credit card can be charged. Some customers, because of numbers of > items in their catalog don't want to maintain inventory. > > Also, if you have drop shipping from other vendors, you don't know if they > have the item in stock. > > How do you guys reprint orders if the original hard copy is misplaced? > > Steve > > -----Original Message----- > From: Garth Penglase [mailto:garth@;bbmedia.com.au] > Sent: Tuesday, October 22, 2002 7:48 AM > To: Multiple recipients of list witango-talk > 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+2U75yKRAPtV0ZQ02 > mZ2 >>>> >>>> ynXdidrotPUEuIY9N0eCEz22AA+fEd06DNAAAAAlu1KX7S2vKW0PNpdagJS/WQ0sXFVvgPw2t > fZq >>>> OZIeO9xzkjL1zaALW6NWVPsKP7Hf53nTNjRAHj0V9ixa2qWcgAA >>>> >>>> BT_GK2=RHDp9wEAAAACQAAAANpYPBbZhSKJ0OSvdW9MypLdS+UzuAT7D+2U75yKRAPtV0ZQ02 > mZ2 >>>> >>>> ynXdidrotPUEuIY9N0eCEz22AA+fEd06DNAAAAAUX6yYYqMIIKCVTJ71ZoYMoJVMnvVmhgygl > Uye >>>> 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
