Re: Update Databases from Webserver
FreeBSD Mail Lists wrote: > Richard, > Thanks for your reply. I thought there was something terribly wrong with > that logic. So I thought I would ask in this mail list since people have > been great here in the past about everything else I wanted to know. > Are there any security lists in relation to ecommerce that you would > recommend? So I can stop annoying everyone else here. I just don't want > to make anymore mistakes than I have to starting down this road. I don't really know of any good security list... I'd sure be happy to HEAR of one, mind you. To be honest, I suspect there isn't really a good security list, because this is simply the kind of thing that so *FEW* people actually do, that there isn't a critical mass of people doing it and needing help for a good mailing list to exist. Please don't take my "tone" as being annoyed. I basically just wanted to "scare" you into *NOT* doing what you plan to do. It's incredibly dangerous, and carries an inordinate amount of risk. If you absolutely *MUST* do this, hire a security expert to help you design/program it. It's just not a good idea to do what you said you wanted to do on your own your first time. If your boss/manage won't accept that, tell them you'll need all their personal credit cards for testing purposes until you're SURE the system is secure and safe from thieves. They may change their tune at that point. -- Like Music? http://l-i-e.com/artists.htm ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Update Databases from Webserver
> -Original Message- > From: [EMAIL PROTECTED] [mailto:owner-freebsd- > [EMAIL PROTECTED] On Behalf Of Peter Risdon > Sent: Tuesday, September 07, 2004 1:14 PM > To: FreeBSD Mail Lists > Cc: Questions > Subject: Re: Update Databases from Webserver > > FreeBSD Mail Lists wrote: > > Peter, Thanks for your response. In response to > > > >> You don't say why you'd want to do this. If you want to allow > >> customers of an e-commerce site to avoid repeating their details > >> whenever they want to buy, perhaps consider basing the payment > >> backend around PayPal. The need for users to authenticate in order > >> to make a payment hasn't brought e-Bay to its knees. > > > > > > Pretty much the end result would be Amazon like with the customer > > being able to choose a previously used card. Is this possible > > without storing credit card numbers or using paypal? > > > > Well, yes, this is a convenience. But there's a very good reason why you > only find this at very big online retailers like Amazon: It's a biggie. > All the replies you had that I've seen point this out one way or another. Exactly right, I would look for a credit card processing company that supports the functionality you are looking for and use their existing functionality and let them absorb the liability if something horrible were to happen. You generally don't want to be the company or person that is responsible for exposing financial information. Jason > > Peter. > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions- > [EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Update Databases from Webserver
FreeBSD Mail Lists wrote: Peter, Thanks for your response. In response to You don't say why you'd want to do this. If you want to allow customers of an e-commerce site to avoid repeating their details whenever they want to buy, perhaps consider basing the payment backend around PayPal. The need for users to authenticate in order to make a payment hasn't brought e-Bay to its knees. Pretty much the end result would be Amazon like with the customer being able to choose a previously used card. Is this possible without storing credit card numbers or using paypal? Well, yes, this is a convenience. But there's a very good reason why you only find this at very big online retailers like Amazon: It's a biggie. All the replies you had that I've seen point this out one way or another. Peter. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Update Databases from Webserver
Peter, Thanks for your response. In response to > You don't say why you'd want to do this. If you want to allow customers > of an e-commerce site to avoid repeating their details whenever they > want to buy, perhaps consider basing the payment backend around PayPal. > The need for users to authenticate in order to make a payment hasn't > brought e-Bay to its knees. Pretty much the end result would be Amazon like with the customer being able to choose a previously used card. Is this possible without storing credit card numbers or using paypal? Anyway thanks everyone for their replies thus far any input helps. -Troy -Original message- From: Peter Risdon [EMAIL PROTECTED] Date: Tue, 7 Sep 2004 07:18:22 -0600 To: FreeBSD Mail Lists [EMAIL PROTECTED] Subject: Re: Update Databases from Webserver > I'm afraid the awful truth is that if you need to ask this question > here, you shouldn't be storing other people's credit card details on > your server. > > > If you want to use the numbers to confirm identity or something, you > could store an encrypted version of the number and use that for comparison. > > But to start storing plaintext CC details on your system without being > deeply expert in all the security issues raised would be very dangerous. > And the high degree of monitoring needed for such a system would make it > uneconomical without commensurately high volumes of business. > > Peter. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Update Databases from Webserver
On Mon, 6 Sep 2004, FreeBSD Mail Lists wrote: I would like to see how other people are updating backend databases (postgresql on FreeBSD, internal network) from a webserver (apache,php on FreeBSD, dmz network) through a firewall. Pretty much what I am trying to learn is how to take private information (credit card numbers, etc.) and write it to a backend database without leaving any huge holes for hacking. Should this be done or am I barking up the wrong tree, I'm afraid the awful truth is that if you need to ask this question here, you shouldn't be storing other people's credit card details on your server. You don't say why you'd want to do this. If you want to allow customers of an e-commerce site to avoid repeating their details whenever they want to buy, perhaps consider basing the payment backend around PayPal. The need for users to authenticate in order to make a payment hasn't brought e-Bay to its knees. If you want to use the numbers to confirm identity or something, you could store an encrypted version of the number and use that for comparison. But to start storing plaintext CC details on your system without being deeply expert in all the security issues raised would be very dangerous. And the high degree of monitoring needed for such a system would make it uneconomical without commensurately high volumes of business. Peter. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Update Databases from Webserver
On Mon, 6 Sep 2004, FreeBSD Mail Lists wrote: > I would like to see how other people are updating backend databases > (postgresql on FreeBSD, internal network) from a webserver (apache,php > on FreeBSD, dmz network) through a firewall. Pretty much what I am > trying to learn is how to take private information (credit card numbers, > etc.) and write it to a backend database without leaving any huge holes > for hacking. Should this be done or am I barking up the wrong tree, > should there be an intermediary step? I have been trying to find > information books/web that gives a real nuts and bolts way of trying to > do this stuff and am not having a lot of luck. Any pointers books or > sites would be appreciated. First thing to consider - do you -have- to store things like credit card numbers ? Most clearing houses can be negotiated with on-line; during the transaction and all you need to capture is an authorization ack. That already makes things a lot safer. Secondly - carefully consider what you need to have on your webserver; do you really have to store a name/address there long term; or is a login and some preferences enough ? Thirdly consider making the flow a one way street: using things like a PGP email with just the public key on the web server; i.e. shunt any private information into an encrypted email - send it to your systems in-house; and only have the decryption key behind the firewall; and thus only keeping the bare essentials on your server. Dw ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Update Databases from Webserver
On Mon, Sep 06, 2004 at 10:55:42PM -0600 or thereabouts, FreeBSD Mail Lists wrote: > Richard, > Thanks for your reply. I thought there was something terribly wrong > with that logic. So I thought I would ask in this mail list since > people have been great here in the past about everything else I > wanted to know. > Are there any security lists in relation to ecommerce that you > would recommend? So I can stop annoying everyone else here. > I just don't want to make anymore mistakes than I have to > starting down this road. Stop talking like that. You are not annoying anyone in here. You asked the question, you got the replies. Richard wrote nice email. But it would be much better and less painful for you, if you could run your credit card transactions using services of your Bank, or maybe by some kind of well know and trustworthy billing system. Why should you have dreamless nights? Credit card info is very *very* sensitive information. So ask yourself, do you really need to have all the stress or can you leave it to your bank/billing partner (although for small fee)? And mainly, are you well known to your customers, even to those which are new? Because if I am about to give someone my credit card info I will not trust to e-commerce application provider, but to well known bank or such. Cheers, Martin Hudec > > -Original message- > From: "Richard Lynch" [EMAIL PROTECTED] > Date: Mon, 6 Sep 2004 17:22:54 -0600 > To: "FreeBSD Mail Lists" [EMAIL PROTECTED] > Subject: Re: Update Databases from Webserver > > > FreeBSD Mail Lists wrote: > > > I would like to see how other people are updating backend databases > > > (postgresql on FreeBSD, internal network) from a webserver (apache,php on > > > FreeBSD, dmz network) through a firewall. Pretty much what I am trying to > > > learn is how to take private information (credit card numbers, etc.) and > > > write it to a backend database without leaving any huge holes for hacking. > > > Should this be done or am I barking up the wrong tree, should there be an > > > intermediary step? I have been trying to find information books/web that > > > gives a real nuts and bolts way of trying to do this stuff and am not > > > having a lot of luck. Any pointers books or sites would be appreciated. > > > > The most common answer is "Don't do that" > > > > 99.9% of e-commerce sites have absolutely no business storing credit > > card numbers on any hardware they own. > > > > They should simply run the transaction through their Merchant Account > > (bank) computer using a secure connection, and the software provided by > > their Merchant Account (bank). > > > > If you need a recurring charge, you can run your charge through the > > Merchant Account as a "recurring charge" (whoda thunk it?) and the > > Merchant Account software will give you back a unique transaction # to > > refer to if you ever need to cancel THAT particular recurring charge. You > > would store only that transaction number, and *NOT* the customer's credit > > card charge. > > > > In the unlikely event that you really *ARE* in the 0.01% of servers > > that needs to store credit card info... Well, it's kinda scare that > > you're asking here, rather than a security mailing list, but here is *ONE* > > solution that may be worth considering. > > > > I am posting to the list so that others can tell us just how inadequate > > this is. > > > > You should also be aware that by no means am I an "expert" -- I am simply > > describing what has been described to me as the "right way" (tm) to do > > this. > > > > My information may be out of date. (It's been awhile.) > > > > I chose to let the Merchant Account (bank) worry about keeping credit card > > numbers safe, rather than do all of the following. > > > > You probably should too. > > > > Depending on the current interpretation of existing laws, you, the web > > developer, may or may not be held responsible for *ANY* damages that > > result from your work -- no matter how faultless you may be in reality. > > We're talking legalities here, not reality. > > > > Did I mention that you really shouldn't be doing this at all? Good. > > > > > > > > First, your servers *MUST* be in a physically secure location, with access > > limited to *ONLY* people you really really really trust. > > > > No software in the world will do you any damn good if a not-so-honest > > person can
Re: Update Databases from Webserver
Troy, Maybe the 'commercial question' that should be asked is.. "Why do you need this highly troublesome data within your system?" NOTE : I am not expecting you to answer that here in public forum, but maybe you as (potential) sysadmin should be asking it of your CEO, CIO, legal pipple, etc etc. You want to be sure that you have very good paper covering _your_ nether regions! ;-o my 0.02c worth mjt On Tue, 2004-09-07 at 14:55, FreeBSD Mail Lists wrote: > Richard, > Thanks for your reply. I thought there was something terribly wrong with that > logic. So I thought I would ask in this mail list since people have been great here > in the past about everything else I wanted to know. > Are there any security lists in relation to ecommerce that you would recommend? So > I can stop annoying everyone else here. I just don't want to make anymore mistakes > than I have to starting down this road. > > Thanks again, > > Troy > > -Original message- > From: "Richard Lynch" [EMAIL PROTECTED] > Date: Mon, 6 Sep 2004 17:22:54 -0600 > To: "FreeBSD Mail Lists" [EMAIL PROTECTED] > Subject: Re: Update Databases from Webserver > > > FreeBSD Mail Lists wrote: > > > I would like to see how other people are updating backend databases > > > (postgresql on FreeBSD, internal network) from a webserver (apache,php on > > > FreeBSD, dmz network) through a firewall. Pretty much what I am trying to > > > learn is how to take private information (credit card numbers, etc.) and > > > write it to a backend database without leaving any huge holes for hacking. > > > Should this be done or am I barking up the wrong tree, should there be an > > > intermediary step? I have been trying to find information books/web that > > > gives a real nuts and bolts way of trying to do this stuff and am not > > > having a lot of luck. Any pointers books or sites would be appreciated. > > > > The most common answer is "Don't do that" > > > > 99.9% of e-commerce sites have absolutely no business storing credit > > card numbers on any hardware they own. > > > > They should simply run the transaction through their Merchant Account > > (bank) computer using a secure connection, and the software provided by > > their Merchant Account (bank). > > > > If you need a recurring charge, you can run your charge through the > > Merchant Account as a "recurring charge" (whoda thunk it?) and the > > Merchant Account software will give you back a unique transaction # to > > refer to if you ever need to cancel THAT particular recurring charge. You > > would store only that transaction number, and *NOT* the customer's credit > > card charge. > > > > In the unlikely event that you really *ARE* in the 0.01% of servers > > that needs to store credit card info... Well, it's kinda scare that > > you're asking here, rather than a security mailing list, but here is *ONE* > > solution that may be worth considering. > > > > I am posting to the list so that others can tell us just how inadequate > > this is. > > > > You should also be aware that by no means am I an "expert" -- I am simply > > describing what has been described to me as the "right way" (tm) to do > > this. > > > > My information may be out of date. (It's been awhile.) > > > > I chose to let the Merchant Account (bank) worry about keeping credit card > > numbers safe, rather than do all of the following. > > > > You probably should too. > > > > Depending on the current interpretation of existing laws, you, the web > > developer, may or may not be held responsible for *ANY* damages that > > result from your work -- no matter how faultless you may be in reality. > > We're talking legalities here, not reality. > > > > Did I mention that you really shouldn't be doing this at all? Good. > > > > > > > > First, your servers *MUST* be in a physically secure location, with access > > limited to *ONLY* people you really really really trust. > > > > No software in the world will do you any damn good if a not-so-honest > > person can waltz in and play around with the hardware! > > > > If you *CANNOT* guarantee that the hardware in question can *ONLY* be > > accessed by trusted individuals, than you should stop reading right here > > and now. > > > > This rules out shared servers, co-location (IMHO), and almost all > > corporate servers, which need too many people of limited trust va
Re: Update Databases from Webserver
Richard, Thanks for your reply. I thought there was something terribly wrong with that logic. So I thought I would ask in this mail list since people have been great here in the past about everything else I wanted to know. Are there any security lists in relation to ecommerce that you would recommend? So I can stop annoying everyone else here. I just don't want to make anymore mistakes than I have to starting down this road. Thanks again, Troy -Original message- From: "Richard Lynch" [EMAIL PROTECTED] Date: Mon, 6 Sep 2004 17:22:54 -0600 To: "FreeBSD Mail Lists" [EMAIL PROTECTED] Subject: Re: Update Databases from Webserver > FreeBSD Mail Lists wrote: > > I would like to see how other people are updating backend databases > > (postgresql on FreeBSD, internal network) from a webserver (apache,php on > > FreeBSD, dmz network) through a firewall. Pretty much what I am trying to > > learn is how to take private information (credit card numbers, etc.) and > > write it to a backend database without leaving any huge holes for hacking. > > Should this be done or am I barking up the wrong tree, should there be an > > intermediary step? I have been trying to find information books/web that > > gives a real nuts and bolts way of trying to do this stuff and am not > > having a lot of luck. Any pointers books or sites would be appreciated. > > The most common answer is "Don't do that" > > 99.9% of e-commerce sites have absolutely no business storing credit > card numbers on any hardware they own. > > They should simply run the transaction through their Merchant Account > (bank) computer using a secure connection, and the software provided by > their Merchant Account (bank). > > If you need a recurring charge, you can run your charge through the > Merchant Account as a "recurring charge" (whoda thunk it?) and the > Merchant Account software will give you back a unique transaction # to > refer to if you ever need to cancel THAT particular recurring charge. You > would store only that transaction number, and *NOT* the customer's credit > card charge. > > In the unlikely event that you really *ARE* in the 0.01% of servers > that needs to store credit card info... Well, it's kinda scare that > you're asking here, rather than a security mailing list, but here is *ONE* > solution that may be worth considering. > > I am posting to the list so that others can tell us just how inadequate > this is. > > You should also be aware that by no means am I an "expert" -- I am simply > describing what has been described to me as the "right way" (tm) to do > this. > > My information may be out of date. (It's been awhile.) > > I chose to let the Merchant Account (bank) worry about keeping credit card > numbers safe, rather than do all of the following. > > You probably should too. > > Depending on the current interpretation of existing laws, you, the web > developer, may or may not be held responsible for *ANY* damages that > result from your work -- no matter how faultless you may be in reality. > We're talking legalities here, not reality. > > Did I mention that you really shouldn't be doing this at all? Good. > > > > First, your servers *MUST* be in a physically secure location, with access > limited to *ONLY* people you really really really trust. > > No software in the world will do you any damn good if a not-so-honest > person can waltz in and play around with the hardware! > > If you *CANNOT* guarantee that the hardware in question can *ONLY* be > accessed by trusted individuals, than you should stop reading right here > and now. > > This rules out shared servers, co-location (IMHO), and almost all > corporate servers, which need too many people of limited trust value to be > able to access them to keep them up. > > Next, you need a SECOND server which will be used to hold credit card > info, and that second computer will *NOT* be connected to the Internet > (directly) > > You put an extra NIC in your web-server, and run a cross-over cable to the > SECOND server, the extra one, which will hold the credit card numbers. > > You limit ethernet access to that second computer which will hold credit > cards so that *ONLY* the one computer connected to it via the cross-over > cable will be allowed to connect. > > The "extra" NIC in the web-server and the SECOND server are both on a > separate sub-net from everything else in your system. IE, the only > interface cards in your entire organization that utilize the IP address > space in question are those two (2) NICs. > > You then make 100%
Re: Update Databases from Webserver
FreeBSD Mail Lists wrote: > I would like to see how other people are updating backend databases > (postgresql on FreeBSD, internal network) from a webserver (apache,php on > FreeBSD, dmz network) through a firewall. Pretty much what I am trying to > learn is how to take private information (credit card numbers, etc.) and > write it to a backend database without leaving any huge holes for hacking. > Should this be done or am I barking up the wrong tree, should there be an > intermediary step? I have been trying to find information books/web that > gives a real nuts and bolts way of trying to do this stuff and am not > having a lot of luck. Any pointers books or sites would be appreciated. The most common answer is "Don't do that" 99.9% of e-commerce sites have absolutely no business storing credit card numbers on any hardware they own. They should simply run the transaction through their Merchant Account (bank) computer using a secure connection, and the software provided by their Merchant Account (bank). If you need a recurring charge, you can run your charge through the Merchant Account as a "recurring charge" (whoda thunk it?) and the Merchant Account software will give you back a unique transaction # to refer to if you ever need to cancel THAT particular recurring charge. You would store only that transaction number, and *NOT* the customer's credit card charge. In the unlikely event that you really *ARE* in the 0.01% of servers that needs to store credit card info... Well, it's kinda scare that you're asking here, rather than a security mailing list, but here is *ONE* solution that may be worth considering. I am posting to the list so that others can tell us just how inadequate this is. You should also be aware that by no means am I an "expert" -- I am simply describing what has been described to me as the "right way" (tm) to do this. My information may be out of date. (It's been awhile.) I chose to let the Merchant Account (bank) worry about keeping credit card numbers safe, rather than do all of the following. You probably should too. Depending on the current interpretation of existing laws, you, the web developer, may or may not be held responsible for *ANY* damages that result from your work -- no matter how faultless you may be in reality. We're talking legalities here, not reality. Did I mention that you really shouldn't be doing this at all? Good. First, your servers *MUST* be in a physically secure location, with access limited to *ONLY* people you really really really trust. No software in the world will do you any damn good if a not-so-honest person can waltz in and play around with the hardware! If you *CANNOT* guarantee that the hardware in question can *ONLY* be accessed by trusted individuals, than you should stop reading right here and now. This rules out shared servers, co-location (IMHO), and almost all corporate servers, which need too many people of limited trust value to be able to access them to keep them up. Next, you need a SECOND server which will be used to hold credit card info, and that second computer will *NOT* be connected to the Internet (directly) You put an extra NIC in your web-server, and run a cross-over cable to the SECOND server, the extra one, which will hold the credit card numbers. You limit ethernet access to that second computer which will hold credit cards so that *ONLY* the one computer connected to it via the cross-over cable will be allowed to connect. The "extra" NIC in the web-server and the SECOND server are both on a separate sub-net from everything else in your system. IE, the only interface cards in your entire organization that utilize the IP address space in question are those two (2) NICs. You then make 100% sure that you simply cannot get to that SECOND box from anywhere else in the organization. What is quite well-documented is that you use SSL (and ONLY SSL) to allow the customer to get their credit card info to your web-server. You then write some routines to get the credit card numbers from your web-server through your second NIC to the second server. These routines get the fine-tooth code-review treatment, by multiple people. They should be mind-numbingly simple, clearly documented, and do the absolute minimum possible to conduct your business. You test these routines every way you can think of to see how they can be broken. You hire an outside security audit team to test your server and routines to see how they can be broken. You use something like tripwire to raise nine kinds of hell if anything changes on the portion of the web-server that talks to the SECOND machine, and, of course, if anything (other than data) changes on the SECOND machine. Under *NO* circumstances should the routines *EVER* store the credit card numbers in any file, database, shared memory, or anything less transitory than the variables of a single script, operating under SSL, on the web-server. So, in effect, you get
