Re: Creditcard Number Security was Re: Encrypted column - Mailing list pgsql-general

>-----Original Message-----
>From: pgsql-general-owner@postgresql.org
>[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Marko Kreen
>Sent: dinsdag 5 juni 2007 21:38
>To: Peter Childs
>Cc: pgsql-general@postgresql.org
>Subject: Re: Creditcard Number Security was Re: [GENERAL]
>Encrypted column
>
>On 6/5/07, Peter Childs <peterachilds@gmail.com> wrote:
>> On 05/06/07, Andrew Sullivan <ajs@crankycanuck.ca> 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