Creditcard Number Security was Re: 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.

--
marko

-----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

On Tue, Jun 05, 2007 at 07:29:02PM +0100, Peter Childs wrote:

Unfortunately you still need to store them somewhere, and all systems can
be hacked.

Yes. I agree, in principle, that "don't store them" is the best
advice -- this is standard _Translucent Databases_ advice, too. For
the least-stealable data is the data you don't have.

But if there is a business case, you have to do the trade off. And
security is always a tradeoff (to quote Schneier); just do it well.
(Someone else's advice about hiring a security expert to audit this
sort of design is really a good idea.)

A

--
Andrew Sullivan | ajs@crankycanuck.ca
The plural of anecdote is not data.
--Roger Brinner

On Tue, 2007-06-05 at 16:51 -0400, Andrew Sullivan wrote:

On Tue, Jun 05, 2007 at 07:29:02PM +0100, Peter Childs wrote:

Unfortunately you still need to store them somewhere, and all systems can
be hacked.

Yes. I agree, in principle, that "don't store them" is the best
advice -- this is standard _Translucent Databases_ advice, too. For
the least-stealable data is the data you don't have.

But if there is a business case, you have to do the trade off. And
security is always a tradeoff (to quote Schneier); just do it well.
(Someone else's advice about hiring a security expert to audit this
sort of design is really a good idea.)

A

Have you thought about setting up an account with PayPal, and having
people pay through PayPal?

Let PayPal deal with the security, and credit card info, after all it's
what they do.

Guy Fraser wrote:

On Tue, 2007-06-05 at 16:51 -0400, Andrew Sullivan wrote:

Yes. I agree, in principle, that "don't store them" is the best
advice -- this is standard _Translucent Databases_ advice, too. For
the least-stealable data is the data you don't have.

But if there is a business case, you have to do the trade off. And
security is always a tradeoff (to quote Schneier); just do it well.
(Someone else's advice about hiring a security expert to audit this
sort of design is really a good idea.)

Have you thought about setting up an account with PayPal, and having
people pay through PayPal?

Let PayPal deal with the security, and credit card info, after all it's
what they do.

at the day job, when we switched from paypal (who we found very
undependable)
to authorize.net, we were very pleased to discover that authorize.net
would take
care of the credit card numbers for us, so we didn't have to try to
secure them beyond
the usual requirements while the numbers are in transit.

i would definitely recommend outsourcing for this if at all possible.

richard

Richard P. Welty wrote:

Guy Fraser wrote:

Have you thought about setting up an account with PayPal, and having
people pay through PayPal?

Let PayPal deal with the security, and credit card info, after all it's
what they do.

at the day job, when we switched from paypal (who we found very
undependable)
to authorize.net, we were very pleased to discover that authorize.net
would take
care of the credit card numbers for us, so we didn't have to try to
secure them beyond
the usual requirements while the numbers are in transit.

i would definitely recommend outsourcing for this if at all possible.

Paypal has a perception issue - they are perceived as being tightly
linked with eBay. That's a problem in the corporate arena. If my stock
broker were to tell me they do all their financial transactions through
Paypal, I'd probably wonder if they were a legitimate corporation.

Do any of these outsourcers indemnify corporate customers against fraud
or data loss?

--
Guy Rouillier

Guy Rouillier wrote:

Richard P. Welty wrote:

Guy Fraser wrote:

Paypal has a perception issue - they are perceived as being tightly
linked with eBay. That's a problem in the corporate arena. If my stock
broker were to tell me they do all their financial transactions through
Paypal, I'd probably wonder if they were a legitimate corporation.

Do any of these outsourcers indemnify corporate customers against fraud
or data loss?

The problem with paypal is it is NOT a bank and is not held by the same
regulations , insurance standards or liabilities as banks.

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

On Jun 7, 2007, at 4:03 PM, Richard P. Welty wrote:

at the day job, when we switched from paypal (who we found very
undependable)
to authorize.net, we were very pleased to discover that
authorize.net would take
care of the credit card numbers for us, so we didn't have to try to
secure them beyond
the usual requirements while the numbers are in transit.

Can you provide a pointer to the documentation where you set things
up for repeated future transactions against the same card?

Thanks,

John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL

John DeSoi wrote:

On Jun 7, 2007, at 4:03 PM, Richard P. Welty wrote:

at the day job, when we switched from paypal (who we found very
undependable)
to authorize.net, we were very pleased to discover that authorize.net
would take
care of the credit card numbers for us, so we didn't have to try to
secure them beyond
the usual requirements while the numbers are in transit.

Can you provide a pointer to the documentation where you set things up
for repeated future transactions against the same card?

i will ask the developer who set it up. i do know that we're handling
monthly recurring
credit card billing via authorize.net in a very reliable way with no
card numbers on any
of our systems.

richard

Joshua D. Drake wrote:

Guy Rouillier wrote:

Richard P. Welty wrote:

Guy Fraser wrote:

Paypal has a perception issue - they are perceived as being tightly
linked with eBay. That's a problem in the corporate arena. If my stock
broker were to tell me they do all their financial transactions through
Paypal, I'd probably wonder if they were a legitimate corporation.

Do any of these outsourcers indemnify corporate customers against fraud
or data loss?

The problem with paypal is it is NOT a bank and is not held by the same
regulations , insurance standards or liabilities as banks.

My "bank" is also "not a bank" (they say they are not "FDIC insured"
which I think is the actual problem at hand). Do I have to be worried?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:

My "bank" is also "not a bank" (they say they are not "FDIC insured"
which I think is the actual problem at hand). Do I have to be worried?

Depends what you use it for. If this is an online bank that you use
only for online transactions and you maintain a balance of say $800, you
probably don't have to worry. If on the other hand this is your only
bank and you have your life savings in there, you most definitely should
consider the risks to which you are exposing your finances.

--
Guy Rouillier

Joshua D. Drake wrote:

Guy Rouillier wrote:

Richard P. Welty wrote:

Guy Fraser wrote:

Paypal has a perception issue - they are perceived as being tightly
linked with eBay. That's a problem in the corporate arena. If my
stock broker were to tell me they do all their financial transactions
through Paypal, I'd probably wonder if they were a legitimate
corporation.

Do any of these outsourcers indemnify corporate customers against
fraud or data loss?

The problem with paypal is it is NOT a bank and is not held by the same
regulations , insurance standards or liabilities as banks.

You should update - paypal is a bank now. But anyway CC processors
are in fact liable with high penalties for CC data. You must be carefull
to fullfill PCI and other requirements or you loose your contracts
with CC aquirers and banks.

Tino