Thread: Creditcard Number Security was Re: Encrypted column
On 05/06/07, Andrew Sullivan <ajs@crankycanuck.ca> wrote:
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. 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.
A
Peter.
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