Re: [PHP] Credit card storing, for processing
Brian Dunning wrote: Source for these statistics? I pulled them from the MYASS database. priceless -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit card storing, for processing
Source for these statistics? I pulled them from the MYASS database. Now that's priceless. Thanks Brian, you've made my day! I wish I could take credit. Many versions of this have gone around, but here's one: http://www.crapco.com/badads/myass.html So much for my earlier post about keeping this thread relevant and helpful. :) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit card storing, for processing
Brian Dunning wrote: Source for these statistics? I pulled them from the MYASS database. Now that's priceless. Thanks Brian, you've made my day! -- John C. Nichel ÜberGeek KegWorks.com 716.856.9675 [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit card storing, for processing
Source for these statistics? I pulled them from the MYASS database. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Credit card storing, for processing
Brandon Thompson wrote: > WowI was hoping someone would respond with a little balance to that > reactionary doomsday speech. Don't get me wrong...those are some very > valid > points that need to be considered, but my gosh... I'd rather frighten away somebody from storing CCs insecurely than blithely stand by while they risk a small fortune and the [client's] customers for all time. > The key-pair idea is very good. I've done systems in the past for clients > that work in a similar fashion. Why? What reason is there for doing this instead of just letting the credit card vendor store the credit card numbers and setting up a recurring charge? Convince me it's a valid reason, and I'll talk welcome more discussion about how to do it securely. Otherwise, I remain the doom-sayer: DON'T DO IT > There are multiple layers of security with two main aspects: > 1. The technical implemenation and complexity of the system > 2. The responsibility/priveledges granted to users/admins > > You can come up with the most complex, technical "secret key" solution > around (aspect #1)but if you entrust that secret key to the wrong > person > (aspect #2), it's all for nothing. NO! It's not about who you trust: It's about who can BREAK IN and gain access to the trusted user/admin area. Or the physical devices and bypass your security completely. I trusted my client completely and implicitly. I did NOT trust every single employee, customer, or visitor who could wander into his office, co-location space, etc. If you do *NOT* have documented processes in place for how you will keep out the Bad Guys to every link of the processing chain, software and hardware, where the credit card number will exist, however briefly, then you have no business storing credit card numbers. > In the end...it's about common sense. It's FAR less dangerous to > implement > what you are suggesting than it is to simply pay for your dinner with a > credit card. Which is FAR less dangerous than Christmas shopping with a credit card. That doesn't make it safe. Playing with M-80s is FAR less dangerous than playing with dynamite, which is FAR less dangerous than playing with nitroglycerine. NONE of them are "safe" and if you don't follow established procedures and policies, it's just plain stupid to do it. > One thing I agree with Richard wholeheartedly on is his "Hi, I'm about to > perform brain surgery. Which scalpel should I use?" anology. If the > technicaly aspects of implementing a system like this escape you...then > please learn how to do it in theory first. Don't "learn on the job" with > something as precious as your credit rating. It was clear, to me at least, that the original poster did NOT have a good grasp on some rather large issues. More importantly, NOTHING posted indicated a true need to store credit card numbers. So, to simplify: If you don't NEED to store credit card numbers, if you can find ANY way to *NOT* store credit card numbers, then you will save a TON of money by not storing them, because storing them comes with a very very very large price tag in development, maintenance, auditing, and ongoing physical security of all hardware involved. If you absolutely HAVE to store credit card numbers, be prepared to shell out tens of thousands on an annual basis to keep them safe. If that's too expensive, then you're not ready to store credit card numbers. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit card storing, for processing
Brian Dunning wrote: > I agree with this. There is way too much paranoia about credit cards > online. 99% of stolen credit card numbers are acquired by phishing and > the other 1% by uncrumpling receipts out of a wastebasket. There's no > longer any reason to go to the trouble of trying to crack encryption. > Remember the knight who went into battle wearing armor only on his > legs? Source for these statistics? Cuz I believe the crumpled paper is MUCH higher than that, from resources I've consulted. However, phishing may be much higher than in the past, so would love to learn where you got these numbers. Or if you just made them up and wanted to imply that compromised servers are the almost-zero that's fine too -- Just want to know if these are "real" stats or made-up. I would guess that 99%++ are still from external sources (phish + paper), rather than compromised servers. But I am *NOT* willing to be the one unlucky guy who loses $50K and all my customers from a compromised server -- And I simply won't implement something that would let my client be that one unlucky guy. The credit card companies charge exhorbitant rates and fees and whatnot to cover the losses to these things, and they have the resources to better manage the data safely. Let *THEM* worry about it. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit card storing, for processing
It depends on the exact situation, but a lot of times the vendors that process a fraudulent credit card purchase end up eating that loss. I can testify to this by experience. I ate $10,000 on one run of phished transactions. the other 1% by uncrumpling receipts out of a wastebasket. There's no longer any reason to go to the trouble of trying to crack encryption. Remember the knight who went into battle wearing armor only on his legs? I suppose that if you want to disregard the risk as minimal, Did I say that, or are you being argumentative? Let's keep the thread useful to the original poster. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit card storing, for processing
Brian Dunning wrote: It's FAR less dangerous to implement what you are suggesting than it is to simply pay for your dinner with a credit card. I agree with this. There is way too much paranoia about credit cards online. 99% of stolen credit card numbers are acquired by phishing and It depends on the exact situation, but a lot of times the vendors that process a fraudulent credit card purchase end up eating that loss. At that point their only recourse is to go after the person that perpetrated the fraud. In the case of phishing it is whomever harvested the cc#. However, in the case of getting cc#'s from your website it is both the person that cracked your site *as well as you*. the other 1% by uncrumpling receipts out of a wastebasket. There's no longer any reason to go to the trouble of trying to crack encryption. Remember the knight who went into battle wearing armor only on his legs? I suppose that if you want to disregard the risk as minimal, well, that's your business. However, even if you believe that the risk of someone stealing your customer's credit card numbers from your server is minimal you still *must* consider the potential cost of being compromised. My financial colleagues would state this as: expected cost = probability * (drop in future sales revenue + attorney litigation fees + damages awarded in lawsuit) Perhaps it's not clear, but litigation might include lawsuits from the credit card company... or the hundreds of *other* companies that get screwed by the fraudulent credit card purchases. Even if you manage to win all of those lawsuits, the litigation fees alone are likely enough to bankrupt you. So even if you only think the probability of being compromised is 1 / 1000... do the math... is it really worth it for you to do this? -- Teach a man to fish... NEW? | http://www.catb.org/~esr/faqs/smart-questions.html STFA | http://marc.theaimsgroup.com/?l=php-general&w=2 STFM | http://www.php.net/manual/en/index.php STFW | http://www.google.com/search?q=php LAZY | http://mycroft.mozdev.org/download.html?name=PHP&submitform=Find+search+plugins -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit card storing, for processing
It's FAR less dangerous to implement what you are suggesting than it is to simply pay for your dinner with a credit card. I agree with this. There is way too much paranoia about credit cards online. 99% of stolen credit card numbers are acquired by phishing and the other 1% by uncrumpling receipts out of a wastebasket. There's no longer any reason to go to the trouble of trying to crack encryption. Remember the knight who went into battle wearing armor only on his legs? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit card storing, for processing
The SIMPLEST way to do this is to charge their credit card with a recurring charge when they sign up, and then just THROW AWAY their credit card number. Your credit card processing vendor then has to remember their credit card number, not you. I agree. This is the way I've worked for years, and it has always worked perfectly. Not once have I ever had all 16 digits of a customer's credit card. I can't even get it from my provider (first 4 and last 4 only). Authorize when they order, store the transaction ID, settle the transaction by ID later in the future if the order goes through. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Credit card storing, for processing
WowI was hoping someone would respond with a little balance to that reactionary doomsday speech. Don't get me wrong...those are some very valid points that need to be considered, but my gosh... The key-pair idea is very good. I've done systems in the past for clients that work in a similar fashion. There are multiple layers of security with two main aspects: 1. The technical implemenation and complexity of the system 2. The responsibility/priveledges granted to users/admins You can come up with the most complex, technical "secret key" solution around (aspect #1)but if you entrust that secret key to the wrong person (aspect #2), it's all for nothing. In the end...it's about common sense. It's FAR less dangerous to implement what you are suggesting than it is to simply pay for your dinner with a credit card. One thing I agree with Richard wholeheartedly on is his "Hi, I'm about to perform brain surgery. Which scalpel should I use?" anology. If the technicaly aspects of implementing a system like this escape you...then please learn how to do it in theory first. Don't "learn on the job" with something as precious as your credit rating. Hope this helps Brandon > -Original Message- > From: Richard Lynch [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 02, 2005 1:34 PM > To: Angelo Zanetti > Cc: php-general@lists.php.net > Subject: Re: [PHP] Credit card storing, for processing > > Angelo Zanetti wrote: > > thanks for the info. With regard to the setup it will be something > > more or less like this: > > DON'T DO IT!!! > > > I want to generate my own keypair. The private key I keep secure, > > offline, on the machine that does the admin (charging, > refunds etc). > > The public > > > > key is used on the server to encrypt card details the minute they > > arrive on the server (even using SSL, the data will arrive > unencrypted > > because the web server decrypts it). > > > > Encrypted card details are written to file, and moved off > the server > > overnight by a cron job. > > > > On the admin machine, offline, the details get decrypted > when needed > > to perform transactions, using the private key. > > Who has access to the private key? > > Under what circumstances? > > How are you going to STOP a determined individual from > compromising the access to the private key? > > Do you have $50,000 in escrow for *WHEN* (not if, *WHEN*) > that key is compromised? > > Are you prepared to put another $100,000 in escrow *after* > that time for the next time it *WILL* happen? > > Are you prepared to contact EVERY credit card customer and > tell them their credit card security was compromised? > > > The admin box is on ADSL, but behind a firewall with no services or > > ports open to the internet. I.e it can initiate a > connection to the > > server on the internet, but not the other way around. > > > > Does this setup sound secure enough and a solution that can work? > > NO! > > Who has physical access to the admin box? > > How is it locked down? > > When will the audits be conducted? > > By whom? > > You're missing about a ZILLION things here... > > > What kind of encryption should I be using? > > If you have to ask, you shouldn't be doing this: > > "Hi, I'm about to perform brain surgery. Which scalpel should I use?" > > You are NOT ready to implement the system you have envisioned. > > Let the credit card companies take the risk. They've got the > resources for it. That's why things are the way they are. > > I *almost* did the same kind of thing you are about to do. > Thank [deity] I came to my senses first. > > I cannot stress this enough. > > DON'T DO IT! > > Sorry, dude. It's just *NOT* a Good Idea. Deal with it. :-) > > -- > Like Music? > http://l-i-e.com/artists.htm > > -- > PHP General Mailing List (http://www.php.net/) To > unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit card storing, for processing
Angelo Zanetti wrote: > thanks for the info. With regard to the setup it will be something more > or less like this: DON'T DO IT!!! > I want to generate my own keypair. The private key I keep secure, > offline, > on the machine that does the admin (charging, refunds etc). The public > > key is used on the server to encrypt card details the minute they > arrive > on the server (even using SSL, the data will arrive unencrypted > because the web server decrypts it). > > Encrypted card details are written to file, and moved off the server > overnight by a cron job. > > On the admin machine, offline, the details get decrypted when needed > to perform transactions, using the private key. Who has access to the private key? Under what circumstances? How are you going to STOP a determined individual from compromising the access to the private key? Do you have $50,000 in escrow for *WHEN* (not if, *WHEN*) that key is compromised? Are you prepared to put another $100,000 in escrow *after* that time for the next time it *WILL* happen? Are you prepared to contact EVERY credit card customer and tell them their credit card security was compromised? > The admin box is on ADSL, but behind a firewall with no services or > ports > open to the internet. I.e it can initiate a connection to the server > on > the internet, but not the other way around. > > Does this setup sound secure enough and a solution that can work? NO! Who has physical access to the admin box? How is it locked down? When will the audits be conducted? By whom? You're missing about a ZILLION things here... > What kind of encryption should I be using? If you have to ask, you shouldn't be doing this: "Hi, I'm about to perform brain surgery. Which scalpel should I use?" You are NOT ready to implement the system you have envisioned. Let the credit card companies take the risk. They've got the resources for it. That's why things are the way they are. I *almost* did the same kind of thing you are about to do. Thank [deity] I came to my senses first. I cannot stress this enough. DON'T DO IT! Sorry, dude. It's just *NOT* a Good Idea. Deal with it. :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit card storing, for processing
On Wed, 02 Feb 2005 01:24:18 -0500, Angelo Zanetti <[EMAIL PROTECTED]> wrote: > > Does this setup sound secure enough and a solution that can work? > What kind of encryption should I be using? > > Point out any areas where you think I might be missing something or > going wrong. Take Richard's advice and don't do it - Any decent Merchant Service Provider should give you a method of placing recurring charges, which would take most of the responsibility and liability out of your hands. If you're even thinking of storing credit card numbers you should have already read and be familiar with the PCI Data Security Standard. http://www.visaeurope.com/acceptingvisa/pdf/PCI_Data_Security_Standard_1_0.pdf You'll have added up the costs of not only building all that, but also the costs of maintaining it, the continuous monitoring, the (at least) quarterly vulnerability scans, incidence response plans etc. You should also know the risks of not following the cards security policies; last time I looked, Visa's compliance penalties were $50,000 for a first offence and $100,000 for subsequent offences, plus the risk of being permanently barred from holding a merchant account. You must also have considered what effect it would have on your business if you have to inform all your customers that their credit card details have been compromised. Storing card details is a high cost, high risk solution. Unless you've a *really* good business reason for doing so that you've not mentioned, it's not a good idea. -robin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit card storing, for processing
HI Richard, thanks for the info. With regard to the setup it will be something more or less like this: I want to generate my own keypair. The private key I keep secure, offline, on the machine that does the admin (charging, refunds etc). The public key is used on the server to encrypt card details the minute they arrive on the server (even using SSL, the data will arrive unencrypted because the web server decrypts it). Encrypted card details are written to file, and moved off the server overnight by a cron job. On the admin machine, offline, the details get decrypted when needed to perform transactions, using the private key. The admin box is on ADSL, but behind a firewall with no services or ports open to the internet. I.e it can initiate a connection to the server on the internet, but not the other way around. Does this setup sound secure enough and a solution that can work? What kind of encryption should I be using? Point out any areas where you think I might be missing something or going wrong. Thanks in advance. Angelo >>> "Richard Lynch" <[EMAIL PROTECTED]> 01/31/05 8:37 PM >>> Angelo Zanetti wrote: > this might be slightly OT but I know that the list has quite a > knowledgable crowd =) So here is my situation: > > I have a client who I have developed a site for in PHP it provides > various models for shares forecasts, the way it works is that people > register for free (with their credit card details-https) now if they > are > not satisfied after a month they must just unsubscribe. If they have > not > unsubscribed after the first month they become a customer and each > month > their credit card is charged the relevant amount depending on what > they > have subscribed for. > > Now our the complication is as follows: I know that storing client's > credit card details online is a big NONO, so we would have to move the > credit card details offline when they register. Im not sure how to go > about this. Whether to save the details in text files somewhere else > on > the server or save to text files not on the server but another > location. > > Can anyone recommend/advise the best way to do this, also what type of > encryption should I be using for the credit card info? The SIMPLEST way to do this is to charge their credit card with a recurring charge when they sign up, and then just THROW AWAY their credit card number. Your credit card processing vendor then has to remember their credit card number, not you. You'll get a one-time transaction identification from the credit card server that you can use to manage their account -- You can then use THAT one-time transaction number to cancel their account, issue refunds, etc. without remembering their credit card number at all. You MIGHT even be able to set this recurring charge to not start until a month later, so you're all set. Given the sheer number of sites and services that have a free trial period, it's very very very likely that the credit card vendors are already all set up to handle this for you. If not, you can almost for sure set the recurring charge, then reverse out the first month's transaction, leaving the rest intact, so they get their free month. You do *NOT* want to store their credit card info *ANYWHERE* at all, period, if you can avoid it. For sure, you do *NOT* store it in a text file on that server, and probably not even in a text file on some other server. If you absolutely MUST store their credit card info, re-post again, explaning WHY, and you'll get some advice. Be warned that that advice will probably involve buying more computer hardware, and hours and hours of setup, as well as a physically secure location, and an independent audit by a security expert, and ... Let's just say "Lots of time and money" Go read the credit card vendor's manual -- I'm willing to bet you can have a solution in hours that doesn't involve you storing credit card numbers. -- Like Music? http://l-i-e.com/artists.htm Disclaimer This e-mail transmission contains confidential information, which is the property of the sender. The information in this e-mail or attachments thereto is intended for the attention and use only of the addressee. Should you have received this e-mail in error, please delete and destroy it and any attachments thereto immediately. Under no circumstances will the Cape Peninsula University of Technology or the sender of this e-mail be liable to any party for any direct, indirect, special or other consequential damages for any use of this e-mail. For the detailed e-mail disclaimer please refer to http://www.ctech.ac.za/polic or call +27 (0)21 460 3911 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit card storing, for processing
Angelo Zanetti wrote: > this might be slightly OT but I know that the list has quite a > knowledgable crowd =) So here is my situation: > > I have a client who I have developed a site for in PHP it provides > various models for shares forecasts, the way it works is that people > register for free (with their credit card details-https) now if they > are > not satisfied after a month they must just unsubscribe. If they have > not > unsubscribed after the first month they become a customer and each > month > their credit card is charged the relevant amount depending on what > they > have subscribed for. > > Now our the complication is as follows: I know that storing client's > credit card details online is a big NONO, so we would have to move the > credit card details offline when they register. Im not sure how to go > about this. Whether to save the details in text files somewhere else > on > the server or save to text files not on the server but another > location. > > Can anyone recommend/advise the best way to do this, also what type of > encryption should I be using for the credit card info? The SIMPLEST way to do this is to charge their credit card with a recurring charge when they sign up, and then just THROW AWAY their credit card number. Your credit card processing vendor then has to remember their credit card number, not you. You'll get a one-time transaction identification from the credit card server that you can use to manage their account -- You can then use THAT one-time transaction number to cancel their account, issue refunds, etc. without remembering their credit card number at all. You MIGHT even be able to set this recurring charge to not start until a month later, so you're all set. Given the sheer number of sites and services that have a free trial period, it's very very very likely that the credit card vendors are already all set up to handle this for you. If not, you can almost for sure set the recurring charge, then reverse out the first month's transaction, leaving the rest intact, so they get their free month. You do *NOT* want to store their credit card info *ANYWHERE* at all, period, if you can avoid it. For sure, you do *NOT* store it in a text file on that server, and probably not even in a text file on some other server. If you absolutely MUST store their credit card info, re-post again, explaning WHY, and you'll get some advice. Be warned that that advice will probably involve buying more computer hardware, and hours and hours of setup, as well as a physically secure location, and an independent audit by a security expert, and ... Let's just say "Lots of time and money" Go read the credit card vendor's manual -- I'm willing to bet you can have a solution in hours that doesn't involve you storing credit card numbers. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
