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+2U75yKRAPtV0ZQ0 2mZ2 > >>> > >>>ynXdidrotPUEuIY9N0eCEz22AA+fEd06DNAAAAAlu1KX7S2vKW0PNpdagJS/WQ0sXFVvgPw2 tfZq > >>> OZIeO9xzkjL1zaALW6NWVPsKP7Hf53nTNjRAHj0V9ixa2qWcgAA > >>> > >>>BT_GK2=RHDp9wEAAAACQAAAANpYPBbZhSKJ0OSvdW9MypLdS+UzuAT7D+2U75yKRAPtV0ZQ0 2mZ2 > >>> > >>>ynXdidrotPUEuIY9N0eCEz22AA+fEd06DNAAAAAUX6yYYqMIIKCVTJ71ZoYMoJVMnvVmhgyg 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
