I agree. I do the same thing. If I was an Amazon or apple or dell it would be different but for a small to mid size business it makes sense not to store. -- Dan Stein Digital Software Solutions 799 Evergreen Circle Telford PA 18969 Land: 215-799-0192 Mobile: 610-256-2843 Fax 413-410-9682 FMP, WiTango, EDI,SQL 2000 [EMAIL PROTECTED] www.dss-db.com
> From: Web Dude <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Date: Tue, 22 Oct 2002 07:39:52 -0500 > To: Multiple recipients of list witango-talk <[EMAIL PROTECTED]> > Subject: Re: Witango-Talk: Encrypting Credit Card Info within the Database > > 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+2U75yKRAPtV0ZQ02mZ2 >>> >>> ynXdidrotPUEuIY9N0eCEz22AA+fEd06DNAAAAAlu1KX7S2vKW0PNpdagJS/WQ0sXFVvgPw2tfZq >>> OZIeO9xzkjL1zaALW6NWVPsKP7Hf53nTNjRAHj0V9ixa2qWcgAA >>> >>> BT_GK2=RHDp9wEAAAACQAAAANpYPBbZhSKJ0OSvdW9MypLdS+UzuAT7D+2U75yKRAPtV0ZQ02mZ2 >>> >>> ynXdidrotPUEuIY9N0eCEz22AA+fEd06DNAAAAAUX6yYYqMIIKCVTJ71ZoYMoJVMnvVmhgyglUye >>> 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
