>-----Original Message----- >From: pgsql-general-owner@xxxxxxxxxxxxxx >[mailto:pgsql-general-owner@xxxxxxxxxxxxxx] On Behalf Of Marko Kreen >Sent: dinsdag 5 juni 2007 21:38 >To: Peter Childs >Cc: pgsql-general@xxxxxxxxxxxxxx >Subject: Re: Creditcard Number Security was Re: [GENERAL] >Encrypted column > >On 6/5/07, Peter Childs <peterachilds@xxxxxxxxx> wrote: >> On 05/06/07, Andrew Sullivan <ajs@xxxxxxxxxxxxxxx> wrote: >> > On Tue, Jun 05, 2007 at 09:28:00AM -0500, Ron Johnson wrote: >> > > >> > > If he is a CC customer, the system (which I am DBA of) bills his >> > > card directly, saving the customer much time and effort. >> > >> > So surely what you have is a completely separate system that has >> > exactly one interface to it, that is signaled to provide a >> > transaction number and that only ever returns such a transaction >> > number to the "online" system, and that is very tightly secured, >> > right? >> > >> > It is possible to make trade-offs in an intelligent manner, for >> > sure, but you sure as heck don't want that kind of data stored >> > online with simple reversible encryption. >> >> Unfortunately you still need to store them somewhere, and all >> systems can be hacked. Yes its a good idea to store them on a >> separate system and this is an important part of designing your >> systems to ensure that the simple user interface is somehow limited. > >If you really need the number in cleartext you should use >public-key encryption, either via pgcrypto or in application. > >Thus you can have only public-key in public database, >credit-card numbers are encrypted with it, later actual >billing happens in separate, highly secured system that has >corresponding private key available to decrypt the data. Even better is to have security experts/specialists design and formally validate the system before use. In general people will screw up security in so much ways that it easilly goes beyond your imagination. You can also take established systems, like kerberos. The problem here is the integration of different data systems. But generally these systems (not all) are well-designed and have received attention from specialists, giving you a much higher confidence in their secure operation than something you build yourselfs. Of course, this still doesn't mean the entire system you are buidling is secure. For elaboration only: Obviously for credit cards we are looking only at the database. Did anyone realize where the credit cards numbers happened to pass through? First of, at the user side they are entered into the browser. Then they are (securely) transmitted to the web server, which already can see them. Eventually they end up in a database and get send to a bank. Obviously putting the information using public key encyrption in a database isn't going to help you securing your web server, is it? So though considering a small part of the system, many important aspects are already overlooked. Yet the weakest chain determines the strength of the entire system. Leave security to specialist, it's a really really hard to get right. - Joris Dobbelsteen
