Re: [PHP] Credit Card encryption
On Tue, 2010-06-01 at 19:39 -0700, Michael Shadle wrote: > Is this a joke? > > Better hope your merchant provider isn't lookin... > > > On Jun 1, 2010, at 7:17 PM, Brandon Rampersad > wrote: > > > I store CC # in plain text on my custom ecommerse website script so > > i can > > compare it with others. That way it's easier to convert to different > > hashes > > when i decide to integrate an encryption system. So far i havent had > > any > > problems. > > > > On Tue, Jun 1, 2010 at 11:15 AM, Paul M Foster > >wrote: > > > >> On Tue, Jun 01, 2010 at 10:42:11AM -0400, tedd wrote: > >> > >>> At 9:24 PM -0400 5/31/10, Paul M Foster wrote: > On Mon, May 31, 2010 at 05:06:23PM -0400, tedd wrote: > > > At 12:36 PM -0400 5/31/10, I wrote: > >> That's Okay, but I'm simply telling you what I KNOW to be true. > >> You > >> may either accept what I have to say, or reject it, but to reply > >> that what I say is "Not true" is somewhat offensive and > >> confrontational. I hope you didn't mean it that way. :-) > > > > My apologies for taking what you said as I did and my reply -- > > it was > > wrong of me. I am sure you didn't mean anything offensive. > > You are correct. I meant no offense. In turn, when I read your > post, it > appeared that you were making a blanket statement applicable > under all > conditions, to which I objected. However, reading back over it, > you did > insert qualifiers. > > Paul > >>> > >>> Okay, let's not get a room over this. :-) > >> > >> Yes, dear. ;-} > >> > >> Paul > >> > >> -- > >> Paul M. Foster > >> > >> -- > >> PHP General Mailing List (http://www.php.net/) > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > > > > > > -- > > A Brandon_R Production > Yeah, I'm pretty sure this is illegal, and if it isn't in your country, then it's sure gonna be against the terms and conditions of your merchant provider. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Credit Card encryption
Is this a joke? Better hope your merchant provider isn't lookin... On Jun 1, 2010, at 7:17 PM, Brandon Rampersad wrote: I store CC # in plain text on my custom ecommerse website script so i can compare it with others. That way it's easier to convert to different hashes when i decide to integrate an encryption system. So far i havent had any problems. On Tue, Jun 1, 2010 at 11:15 AM, Paul M Foster >wrote: On Tue, Jun 01, 2010 at 10:42:11AM -0400, tedd wrote: At 9:24 PM -0400 5/31/10, Paul M Foster wrote: On Mon, May 31, 2010 at 05:06:23PM -0400, tedd wrote: At 12:36 PM -0400 5/31/10, I wrote: That's Okay, but I'm simply telling you what I KNOW to be true. You may either accept what I have to say, or reject it, but to reply that what I say is "Not true" is somewhat offensive and confrontational. I hope you didn't mean it that way. :-) My apologies for taking what you said as I did and my reply -- it was wrong of me. I am sure you didn't mean anything offensive. You are correct. I meant no offense. In turn, when I read your post, it appeared that you were making a blanket statement applicable under all conditions, to which I objected. However, reading back over it, you did insert qualifiers. Paul Okay, let's not get a room over this. :-) Yes, dear. ;-} Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- A Brandon_R Production -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
I store CC # in plain text on my custom ecommerse website script so i can compare it with others. That way it's easier to convert to different hashes when i decide to integrate an encryption system. So far i havent had any problems. On Tue, Jun 1, 2010 at 11:15 AM, Paul M Foster wrote: > On Tue, Jun 01, 2010 at 10:42:11AM -0400, tedd wrote: > > > At 9:24 PM -0400 5/31/10, Paul M Foster wrote: > >> On Mon, May 31, 2010 at 05:06:23PM -0400, tedd wrote: > >> > >>> At 12:36 PM -0400 5/31/10, I wrote: > That's Okay, but I'm simply telling you what I KNOW to be true. You > may either accept what I have to say, or reject it, but to reply > that what I say is "Not true" is somewhat offensive and > confrontational. I hope you didn't mean it that way. :-) > >>> > >>> My apologies for taking what you said as I did and my reply -- it was > >>> wrong of me. I am sure you didn't mean anything offensive. > >> > >> You are correct. I meant no offense. In turn, when I read your post, it > >> appeared that you were making a blanket statement applicable under all > >> conditions, to which I objected. However, reading back over it, you did > >> insert qualifiers. > >> > >> Paul > > > > Okay, let's not get a room over this. :-) > > Yes, dear. ;-} > > Paul > > -- > Paul M. Foster > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- A Brandon_R Production
Re: [PHP] Credit Card encryption
On Tue, Jun 01, 2010 at 10:42:11AM -0400, tedd wrote: > At 9:24 PM -0400 5/31/10, Paul M Foster wrote: >> On Mon, May 31, 2010 at 05:06:23PM -0400, tedd wrote: >> >>> At 12:36 PM -0400 5/31/10, I wrote: That's Okay, but I'm simply telling you what I KNOW to be true. You may either accept what I have to say, or reject it, but to reply that what I say is "Not true" is somewhat offensive and confrontational. I hope you didn't mean it that way. :-) >>> >>> My apologies for taking what you said as I did and my reply -- it was >>> wrong of me. I am sure you didn't mean anything offensive. >> >> You are correct. I meant no offense. In turn, when I read your post, it >> appeared that you were making a blanket statement applicable under all >> conditions, to which I objected. However, reading back over it, you did >> insert qualifiers. >> >> Paul > > Okay, let's not get a room over this. :-) Yes, dear. ;-} Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
On Tue, Jun 01, 2010 at 04:17:21PM +0200, Peter Lind wrote: > On 1 June 2010 15:58, Paul M Foster wrote: > > On Tue, Jun 01, 2010 at 09:52:54AM +0200, Peter Lind wrote: > > > >> Just wondering: seems there's a bit of a misunderstanding going on > >> here. Are you talking about storing credit card information in a way > >> such that customers can do online transactions without entering that > >> information? Or are you talking about storing this information so your > >> own company can fill in the details on a monthly basis? > >> If 1) then the above points apply and you should not store the data, > >> period. If 2) then I would assume the situation is somewhat different > >> - though, not knowing the laws from the US I wouldn't really know. > > > > No to #1, yes to #2. > > > > As for #1, companies like Godaddy do store this information, so I know > > it can be safely done. > > As I noted above: the question is not whether it can be done, the > question is whether you want to be the next critter in the limelight > because *you* couldn't do it. > However, glad to hear you're not looking to do this. That brings up > the next question though: what's this got to do with PHP? If I was to > store any information like this, I certainly wouldn't code my own > storage system with built-in encryption. I would rely on one of the > many adequate cryptography programs available, made specifically for > encrypting and storing data safely. It's got to do with PHP because all the code which handles all this customer data, etc., is PHP. (It's all internal to my network.) You could use mcrypt_*() functions to encrypt the credit card numbers, no problem. Some of the methods of encryption possible with mcrypt are very strong. The original question was if there was an alternative to forcing the user who wants to access the CC number to supply a separate password in order to access the information. The apparent answer (given the original constraints) is no, there is no alternative. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
At 9:52 AM +0200 6/1/10, Peter Lind wrote: Just wondering: seems there's a bit of a misunderstanding going on here. Are you talking about storing credit card information in a way such that customers can do online transactions without entering that information? Or are you talking about storing this information so your own company can fill in the details on a monthly basis? If 1) then the above points apply and you should not store the data, period. If 2) then I would assume the situation is somewhat different - though, not knowing the laws from the US I wouldn't really know. Regards Peter Peter: Yes to the first. I am sure there are all sorts of situations, but in most of the problematic ones I've encountered the clients want to have customers logon and have all their credit card information automatically filled into their forms for purchase. This requires that somewhere on the site all customer's data are kept in a manner that can be accessed and used -- and therein lies the problem. Clients (mine) often think that a web site should be as safe as their brick and mortar operations and as such offer similar services -- namely having a past customer's data waiting and available for immediate purchase without having to brother the customer for it again -- like having a card file. Unfortunately, the security aspects of the web require different thinking -- the web is not brick and mortar, which provides both concern and opportunity. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
At 9:21 PM -0400 5/31/10, Paul M Foster wrote: On Mon, May 31, 2010 at 12:36:55PM -0400, tedd wrote: > What data are used in credit card transactions are the: name of the card holder, credit card number, expiration date, CCV number, and zip code. I have not dealt with any credit card processors that require the billing address -- they just use the zip code. Additionally, it is up to the client to determine the level of security they want. They *can* require that *all* information be correct before accepting a sale. When you say "client" in this context, what do you mean? The ultimate customer, the company issuing the credit card, the bank, the merchant The "client" here would have been my client -- the person who pays me for my service, owns the web site, and is selling product. It is he who has the agreement with the credit card processor and in this case it was a PayPal Merchant service. In the documentation and code PayPal provides there are levels of accessibility/failure you can assign to authorization. You can set it to FAIL if the zip code or CCV are not correct -- however -- it defaults to requiring only the name, expiry date, and credit card number to be correct to PASS. While working on this, I found that the cost for the less secure transaction was higher than for the more secure transaction. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
At 9:24 PM -0400 5/31/10, Paul M Foster wrote: On Mon, May 31, 2010 at 05:06:23PM -0400, tedd wrote: At 12:36 PM -0400 5/31/10, I wrote: That's Okay, but I'm simply telling you what I KNOW to be true. You may either accept what I have to say, or reject it, but to reply that what I say is "Not true" is somewhat offensive and confrontational. I hope you didn't mean it that way. :-) My apologies for taking what you said as I did and my reply -- it was wrong of me. I am sure you didn't mean anything offensive. You are correct. I meant no offense. In turn, when I read your post, it appeared that you were making a blanket statement applicable under all conditions, to which I objected. However, reading back over it, you did insert qualifiers. Paul Okay, let's not get a room over this. :-) Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
On 1 June 2010 15:58, Paul M Foster wrote: > On Tue, Jun 01, 2010 at 09:52:54AM +0200, Peter Lind wrote: > >> Just wondering: seems there's a bit of a misunderstanding going on >> here. Are you talking about storing credit card information in a way >> such that customers can do online transactions without entering that >> information? Or are you talking about storing this information so your >> own company can fill in the details on a monthly basis? >> If 1) then the above points apply and you should not store the data, >> period. If 2) then I would assume the situation is somewhat different >> - though, not knowing the laws from the US I wouldn't really know. > > No to #1, yes to #2. > > As for #1, companies like Godaddy do store this information, so I know > it can be safely done. As I noted above: the question is not whether it can be done, the question is whether you want to be the next critter in the limelight because *you* couldn't do it. However, glad to hear you're not looking to do this. That brings up the next question though: what's this got to do with PHP? If I was to store any information like this, I certainly wouldn't code my own storage system with built-in encryption. I would rely on one of the many adequate cryptography programs available, made specifically for encrypting and storing data safely. Regards Peter -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
On Tue, Jun 01, 2010 at 09:52:54AM +0200, Peter Lind wrote: > Just wondering: seems there's a bit of a misunderstanding going on > here. Are you talking about storing credit card information in a way > such that customers can do online transactions without entering that > information? Or are you talking about storing this information so your > own company can fill in the details on a monthly basis? > If 1) then the above points apply and you should not store the data, > period. If 2) then I would assume the situation is somewhat different > - though, not knowing the laws from the US I wouldn't really know. No to #1, yes to #2. As for #1, companies like Godaddy do store this information, so I know it can be safely done. But no, we do #2. If we were doing #1, I would turn this over to some gateway and not save the info. I'm not sure any of this has to do with laws. It has more to do with the PSS and the rules of individual credit card companies (Visa, American Express, etc.). Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
Just wondering: seems there's a bit of a misunderstanding going on here. Are you talking about storing credit card information in a way such that customers can do online transactions without entering that information? Or are you talking about storing this information so your own company can fill in the details on a monthly basis? If 1) then the above points apply and you should not store the data, period. If 2) then I would assume the situation is somewhat different - though, not knowing the laws from the US I wouldn't really know. Regards Peter -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
On Mon, May 31, 2010 at 05:06:23PM -0400, tedd wrote: > At 12:36 PM -0400 5/31/10, I wrote: >> That's Okay, but I'm simply telling you what I KNOW to be true. You >> may either accept what I have to say, or reject it, but to reply >> that what I say is "Not true" is somewhat offensive and >> confrontational. I hope you didn't mean it that way. :-) > > My apologies for taking what you said as I did and my reply -- it was > wrong of me. I am sure you didn't mean anything offensive. You are correct. I meant no offense. In turn, when I read your post, it appeared that you were making a blanket statement applicable under all conditions, to which I objected. However, reading back over it, you did insert qualifiers. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
On Mon, May 31, 2010 at 12:36:55PM -0400, tedd wrote: > At 1:38 AM -0400 5/31/10, Paul M Foster wrote: >> On Sun, May 30, 2010 at 10:50:05AM -0400, tedd wrote: >> >> > Besides, most credit card processing agencies even require that you >>> use the customer's data (cc number, expiry date and CCS) to make the >>> sale and then immediately dispose of it afterwards, usually within 24 >>> hours under a signed agreement. Holding that information for more >>> than 24 hours can be a criminal offense regardless of what type of >>> hashing you use. >> >> Not true. It depends on the type of merchant and the situation. > > *blink* > > "Not true" and "It depends" are conflicts in logic. > > Either what I said is "true" or it isn't -- and if what I said is > "true" for some (as it is and I can prove it) then what I said is > indeed "true". > > I'm curious, why say it's not "true" and then follow with "it > depends"? It appears to me that you have your mind made-up and don't > care to listen to our experiences and recommendations. > > That's Okay, but I'm simply telling you what I KNOW to be true. You > may either accept what I have to say, or reject it, but to reply that > what I say is "Not true" is somewhat offensive and confrontational. I > hope you didn't mean it that way. :-) Okay, let me be precise, then. I have no idea whether "most credit processing agencies... require" I haven't dealt with "most credit processing agencies", so I have no way of knowing. And in fact, I don't also know whether "holding that information for more than 24 hours can be a criminal offense" This may be a criminal offense where you live, and it may be a criminal offense in Zambatootie as well. Since I'm not familiar with every jurisdiction, I can't vouch for where or when it is a criminal offense. I do know, however, that according to the PCI DSS FAQ, storing a credit card number is discouraged, but not disallowed. Given the proper cryptographic treatment, it is definitely allowed. This also jibes with the self-evaluation questionnaire which Level 4 merchants (like myself) must complete yearly. > > >> The PCI >> validation process allows for storage of all data except the 3-4 digit >> validation number. What I'm asked for at transaction time is the CC >> number, expiration date, digits for the billing address, and the billing >> zip code. And I can get the address and zip digits completely wrong and >> still have the transaction go through. > > Party true. > > What data are used in credit card transactions are the: name of the > card holder, credit card number, expiration date, CCV number, and zip > code. I have not dealt with any credit card processors that require > the billing address -- they just use the zip code. Additionally, it > is up to the client to determine the level of security they want. > They *can* require that *all* information be correct before accepting > a sale. When you say "client" in this context, what do you mean? The ultimate customer, the company issuing the credit card, the bank, the merchant service company? > > The downside of not requiring *all* the data to be correct is that > the rate the credit processor charges for the transaction rises. > Simply and logically put, if you don't get all the information > correct, then there is risk and that risk is passed on to the client > via an elevated charge for processing -- look it up. I have been told repeatedly by my merchant service company that my rates do not and will not rise, should my "verification information" be incorrect. I have been told repeatedly that the collection of this information is for *my* benefit, to lessen the chances of *me* being defrauded. > > The up-side of getting only the minimal data is getting a sale under > a higher risk/rate -- that's the clients choice and they usually > choose it. Again, I'm not sure the definition of client as you are using it. However, I am aware that MOTO merchants (those who take credit cards over the phone, etc. and never have a physical card), like myself, pay higher rates than those who swipe them. Part of the game. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
Billing Address (at least the street number) is used in conjunction with the zip code for AVS checks. On 5/31/10, tedd wrote: > At 1:38 AM -0400 5/31/10, Paul M Foster wrote: >>On Sun, May 30, 2010 at 10:50:05AM -0400, tedd wrote: >> >> > Besides, most credit card processing agencies even require that you >>> use the customer's data (cc number, expiry date and CCS) to make the >>> sale and then immediately dispose of it afterwards, usually within 24 >>> hours under a signed agreement. Holding that information for more >>> than 24 hours can be a criminal offense regardless of what type of >>> hashing you use. >> >>Not true. It depends on the type of merchant and the situation. > > *blink* > > "Not true" and "It depends" are conflicts in logic. > > Either what I said is "true" or it isn't -- and if what I said is > "true" for some (as it is and I can prove it) then what I said is > indeed "true". > > I'm curious, why say it's not "true" and then follow with "it > depends"? It appears to me that you have your mind made-up and don't > care to listen to our experiences and recommendations. > > That's Okay, but I'm simply telling you what I KNOW to be true. You > may either accept what I have to say, or reject it, but to reply that > what I say is "Not true" is somewhat offensive and confrontational. I > hope you didn't mean it that way. :-) > > >>The PCI >>validation process allows for storage of all data except the 3-4 digit >>validation number. What I'm asked for at transaction time is the CC >>number, expiration date, digits for the billing address, and the billing >>zip code. And I can get the address and zip digits completely wrong and >>still have the transaction go through. > > Party true. > > What data are used in credit card transactions are the: name of the > card holder, credit card number, expiration date, CCV number, and zip > code. I have not dealt with any credit card processors that require > the billing address -- they just use the zip code. Additionally, it > is up to the client to determine the level of security they want. > They *can* require that *all* information be correct before accepting > a sale. > > The downside of not requiring *all* the data to be correct is that > the rate the credit processor charges for the transaction rises. > Simply and logically put, if you don't get all the information > correct, then there is risk and that risk is passed on to the client > via an elevated charge for processing -- look it up. > > The up-side of getting only the minimal data is getting a sale under > a higher risk/rate -- that's the clients choice and they usually > choose it. > >>We've been doing it this way for 14 years and using the type of service >>you suggest would be expensive and impractical. Only in the last two >>years has PCI become more stringent in their requirements. And >>consequently, I'm having to re-evaluate how we store this particular >>information. Otherwise, our physical and other security is more than >>adequate. Yes, of course, if you have a machine gun or you're Kevin >>Mitnick, or you have a network of 20,000 bots pounding on my router, >>you're coming in anyway. Again, this is about *reasonable* security. > > You asked for opinions -- do what you want. :-) > > Cheers, > > tedd > > -- > --- > http://sperling.com http://ancientstones.com http://earthstones.com > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Sent from my mobile device -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
At 12:36 PM -0400 5/31/10, I wrote: That's Okay, but I'm simply telling you what I KNOW to be true. You may either accept what I have to say, or reject it, but to reply that what I say is "Not true" is somewhat offensive and confrontational. I hope you didn't mean it that way. :-) My apologies for taking what you said as I did and my reply -- it was wrong of me. I am sure you didn't mean anything offensive. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
At 1:38 AM -0400 5/31/10, Paul M Foster wrote: On Sun, May 30, 2010 at 10:50:05AM -0400, tedd wrote: > Besides, most credit card processing agencies even require that you use the customer's data (cc number, expiry date and CCS) to make the sale and then immediately dispose of it afterwards, usually within 24 hours under a signed agreement. Holding that information for more than 24 hours can be a criminal offense regardless of what type of hashing you use. Not true. It depends on the type of merchant and the situation. *blink* "Not true" and "It depends" are conflicts in logic. Either what I said is "true" or it isn't -- and if what I said is "true" for some (as it is and I can prove it) then what I said is indeed "true". I'm curious, why say it's not "true" and then follow with "it depends"? It appears to me that you have your mind made-up and don't care to listen to our experiences and recommendations. That's Okay, but I'm simply telling you what I KNOW to be true. You may either accept what I have to say, or reject it, but to reply that what I say is "Not true" is somewhat offensive and confrontational. I hope you didn't mean it that way. :-) The PCI validation process allows for storage of all data except the 3-4 digit validation number. What I'm asked for at transaction time is the CC number, expiration date, digits for the billing address, and the billing zip code. And I can get the address and zip digits completely wrong and still have the transaction go through. Party true. What data are used in credit card transactions are the: name of the card holder, credit card number, expiration date, CCV number, and zip code. I have not dealt with any credit card processors that require the billing address -- they just use the zip code. Additionally, it is up to the client to determine the level of security they want. They *can* require that *all* information be correct before accepting a sale. The downside of not requiring *all* the data to be correct is that the rate the credit processor charges for the transaction rises. Simply and logically put, if you don't get all the information correct, then there is risk and that risk is passed on to the client via an elevated charge for processing -- look it up. The up-side of getting only the minimal data is getting a sale under a higher risk/rate -- that's the clients choice and they usually choose it. We've been doing it this way for 14 years and using the type of service you suggest would be expensive and impractical. Only in the last two years has PCI become more stringent in their requirements. And consequently, I'm having to re-evaluate how we store this particular information. Otherwise, our physical and other security is more than adequate. Yes, of course, if you have a machine gun or you're Kevin Mitnick, or you have a network of 20,000 bots pounding on my router, you're coming in anyway. Again, this is about *reasonable* security. You asked for opinions -- do what you want. :-) Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
On May 31, 2010, at 1:24 AM, Paul M Foster wrote: On Sun, May 30, 2010 at 03:30:28PM -0400, Phpster wrote: I work with some of the largest retailers in north America if not the world, and I can confirm that the security measures taken to enforce pci compliance are not something lightly undertaken. If those entities choose to store the cc#s then they do the following: 1. Store the encrypted values on servers that are NOT web facing Absolutely! If I were trying to do this on a web server, I *would* use a payment gateway. There's no way I could secure it adequately otherwise. 2. Use ridiculously long encryption keys ( well into the 1000s of characters) 3. They also create a representative value that exists outside the system that has to allow some basis of data mining. Really as mentioned you don't want to do this. Especially if you have no control over the servers. I have complete control over the server this information is stored on, including physical control. It is behind a NATed firewall and only accessible to certain machines on my internal network. The only personnel with access to the server are myself and my wife. To be clear, we process credit cards MOTO, meaning we have no physical access to the cards themselves. We use a small terminal which dials up our payment processor to get approvals. The problem is that virtually all of our credit card business is with the same customers and recurring. So it's not feasible to call them every month or several times per job to ask for a credit card number. This would aggravate my customers. So I have to store the information one way or another, on 3x5 cards, in the computer or some way. And it appears from all the replies that there is no other way to do it than to have a separate key or password for accessing just these credit card numbers, and every time they must be accessed, the user must provide this key, which would be in addition to the usual password for that user. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php It sounds like a lot of the activity is subscription based, is that correct? Paypal does support that. I would suggest looking thru the oci guidelines if you haven't done so already. The point there are essential requirements and should be enough for you to judge if you can be compliant with the rules. Pci is a total PITA, and the fines are not worth it if you can't meet the requirements. Bastien Sent from my iPod -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
On Sun, May 30, 2010 at 10:50:05AM -0400, tedd wrote: > At 12:43 PM +0200 5/30/10, Peter Lind wrote: >>> On 30 May 2010 07:49, Paul M Foster wrote: >>> -snip- >>> >>> Does anyone have a better solution? >> >> I'm sorry if the following sounds a bit harsh, but in matters like >> these I prefer blunt directness. >> >> A few notes. 1) one-way encryption means "no decrypting" - that's what >> one-way is (like a one-way street, there's no driving the other >> direction). You're looking for encryption that can be decrypted, not >> one-way encryption which is otherwise known as hashing. 2) do not >> store credit card information. Just don't. It's downright stupid to do >> so, because it's a huge risk for very little gain. 3) farm out risks >> like these to companies that specialize in dealing with them - you >> will with 100% certainty not be able to do as good a job as these. >> >> The question to ask is not: how to store credit card information >> securely? The question to ask is: do I really want to be the next >> person in the internet spotlight because my setup turned out to have a >> security hole I overlooked? > > Paul: > > Let me be equally blunt. Petter is absolutely right! > > Do NOT have your client store customer credit card information on a > server -- period! That's the stuff people go to jail over. Instead, > use a credit card clearing house to do the heavy work, that's what > they get paid for. > > Besides, most credit card processing agencies even require that you > use the customer's data (cc number, expiry date and CCS) to make the > sale and then immediately dispose of it afterwards, usually within 24 > hours under a signed agreement. Holding that information for more > than 24 hours can be a criminal offense regardless of what type of > hashing you use. Not true. It depends on the type of merchant and the situation. The PCI validation process allows for storage of all data except the 3-4 digit validation number. What I'm asked for at transaction time is the CC number, expiration date, digits for the billing address, and the billing zip code. And I can get the address and zip digits completely wrong and still have the transaction go through. > > While many of my customers have made the argument that they keep > hard-copy records of their customer's credit-card information > in-house and they don't understand why they can't do the same online > -- I reply that hard-copy kept in a safe behind "brick and mortar" in > far more secure that digital data behind any "security" code open to > the world. There isn't a security system out there that can't be > hacked. If the client insists on keeping this information online, > then find another client because at some time, someone is going to > jail and it's not going to be me. Of course, any system can be hacked. PCI guidelines are designed to ensure that measures are in place to minimize that non-zero risk. > > So, let the people who can keep up with technology (a continued > effort and expense) worry about hackers -- just use their services > and sleep at night. > We've been doing it this way for 14 years and using the type of service you suggest would be expensive and impractical. Only in the last two years has PCI become more stringent in their requirements. And consequently, I'm having to re-evaluate how we store this particular information. Otherwise, our physical and other security is more than adequate. Yes, of course, if you have a machine gun or you're Kevin Mitnick, or you have a network of 20,000 bots pounding on my router, you're coming in anyway. Again, this is about *reasonable* security. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
On Sun, May 30, 2010 at 03:30:28PM -0400, Phpster wrote: > > I work with some of the largest retailers in north America if not the > world, and I can confirm that the security measures taken to enforce > pci compliance are not something lightly undertaken. > > If those entities choose to store the cc#s then they do the following: > > 1. Store the encrypted values on servers that are NOT web facing Absolutely! If I were trying to do this on a web server, I *would* use a payment gateway. There's no way I could secure it adequately otherwise. > > 2. Use ridiculously long encryption keys ( well into the 1000s of > characters) > > 3. They also create a representative value that exists outside the > system that has to allow some basis of data mining. > > > Really as mentioned you don't want to do this. Especially if you have > no control over the servers. I have complete control over the server this information is stored on, including physical control. It is behind a NATed firewall and only accessible to certain machines on my internal network. The only personnel with access to the server are myself and my wife. To be clear, we process credit cards MOTO, meaning we have no physical access to the cards themselves. We use a small terminal which dials up our payment processor to get approvals. The problem is that virtually all of our credit card business is with the same customers and recurring. So it's not feasible to call them every month or several times per job to ask for a credit card number. This would aggravate my customers. So I have to store the information one way or another, on 3x5 cards, in the computer or some way. And it appears from all the replies that there is no other way to do it than to have a separate key or password for accessing just these credit card numbers, and every time they must be accessed, the user must provide this key, which would be in addition to the usual password for that user. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
On Sun, May 30, 2010 at 03:12:10AM -0400, Adam Richardson wrote: > On Sun, May 30, 2010 at 2:16 AM, Ashley Sheridan > wrote: > > > On Sun, 2010-05-30 at 01:49 -0400, Paul M Foster wrote: > > > > Hi Paul, > > When you describe one-way or two-way encryption, what are you describing? > Are you describing hashing vs encryption where the plain-text is > recoverable with a key, or are you describing symmetric (one key handles > encrypting and decrypting) vs asymmetric (separate keys handle encrypting > and decrypting) encryption? I'm not very good with this terminology. What I mean is that there's no way to decrypt the value without the key, and the key is not stored on the system. This would be like password storage on *nix systems-- if you forget the password, there's no practical way to log in. (Yes, I know there are dictionary-based and brute force methods, but in general, if you forget your password, you're screwed.) What PCI wants is strong encryption. I take this to mean that keys are long enough to be practically invulnerable to hacking. > > Now if you one-way encrypt the credit card numbers in the customer > > records, then it seems to me that any time that field has to be accessed > > (to edit the record or charge something to the card), you'd have to have > > the user enter a specific "password" to unlock the encryption. > > > You can't decrypt (or "unlock") a hashed password (at least if you used a > secure hash), but I'm not sure you're talking about symmetric vs asymmetric > encryption, either. With more details , I can provide feedback on the > encryption schemes you're considering (remember, you have to make sure that > you are managing encryption keys very carefully, as among other things, PCI > requires that "keys are stored in encrypted format and that key- encrypting > keys are stored separately from data- encrypting keys.") By "assymetric", I take it you mean like PGP or GPG, where there are public and private keys? I don't really understand this technology, and I'm not sure it matters. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
On May 30, 2010, at 10:50 AM, tedd wrote: At 12:43 PM +0200 5/30/10, Peter Lind wrote: On 30 May 2010 07:49, Paul M Foster wrote: -snip- Does anyone have a better solution? I'm sorry if the following sounds a bit harsh, but in matters like these I prefer blunt directness. A few notes. 1) one-way encryption means "no decrypting" - that's what one-way is (like a one-way street, there's no driving the other direction). You're looking for encryption that can be decrypted, not one-way encryption which is otherwise known as hashing. 2) do not store credit card information. Just don't. It's downright stupid to do so, because it's a huge risk for very little gain. 3) farm out risks like these to companies that specialize in dealing with them - you will with 100% certainty not be able to do as good a job as these. The question to ask is not: how to store credit card information securely? The question to ask is: do I really want to be the next person in the internet spotlight because my setup turned out to have a security hole I overlooked? Paul: Let me be equally blunt. Petter is absolutely right! Do NOT have your client store customer credit card information on a server -- period! That's the stuff people go to jail over. Instead, use a credit card clearing house to do the heavy work, that's what they get paid for. Besides, most credit card processing agencies even require that you use the customer's data (cc number, expiry date and CCS) to make the sale and then immediately dispose of it afterwards, usually within 24 hours under a signed agreement. Holding that information for more than 24 hours can be a criminal offense regardless of what type of hashing you use. While many of my customers have made the argument that they keep hard-copy records of their customer's credit-card information in- house and they don't understand why they can't do the same online -- I reply that hard-copy kept in a safe behind "brick and mortar" in far more secure that digital data behind any "security" code open to the world. There isn't a security system out there that can't be hacked. If the client insists on keeping this information online, then find another client because at some time, someone is going to jail and it's not going to be me. So, let the people who can keep up with technology (a continued effort and expense) worry about hackers -- just use their services and sleep at night. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php I work with some of the largest retailers in north America if not the world, and I can confirm that the security measures taken to enforce pci compliance are not something lightly undertaken. If those entities choose to store the cc#s then they do the following: 1. Store the encrypted values on servers that are NOT web facing 2. Use ridiculously long encryption keys ( well into the 1000s of characters) 3. They also create a representative value that exists outside the system that has to allow some basis of data mining. Really as mentioned you don't want to do this. Especially if you have no control over the servers. Bastien Sent from my iPod -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
On Sun, May 30, 2010 at 11:50 AM, tedd wrote: > At 12:43 PM +0200 5/30/10, Peter Lind wrote: > >> On 30 May 2010 07:49, Paul M Foster wrote: >>> -snip- >>> >>> >>> Does anyone have a better solution? >>> >> >> I'm sorry if the following sounds a bit harsh, but in matters like >> these I prefer blunt directness. >> >> A few notes. 1) one-way encryption means "no decrypting" - that's what >> one-way is (like a one-way street, there's no driving the other >> direction). You're looking for encryption that can be decrypted, not >> one-way encryption which is otherwise known as hashing. 2) do not >> store credit card information. Just don't. It's downright stupid to do >> so, because it's a huge risk for very little gain. 3) farm out risks >> like these to companies that specialize in dealing with them - you >> will with 100% certainty not be able to do as good a job as these. >> >> The question to ask is not: how to store credit card information >> securely? The question to ask is: do I really want to be the next >> person in the internet spotlight because my setup turned out to have a >> security hole I overlooked? >> > > Paul: > > Let me be equally blunt. Petter is absolutely right! > > Do NOT have your client store customer credit card information on a server > -- period! That's the stuff people go to jail over. Instead, use a credit > card clearing house to do the heavy work, that's what they get paid for. > > Besides, most credit card processing agencies even require that you use the > customer's data (cc number, expiry date and CCS) to make the sale and then > immediately dispose of it afterwards, usually within 24 hours under a signed > agreement. Holding that information for more than 24 hours can be a criminal > offense regardless of what type of hashing you use. > > While many of my customers have made the argument that they keep hard-copy > records of their customer's credit-card information in-house and they don't > understand why they can't do the same online -- I reply that hard-copy kept > in a safe behind "brick and mortar" in far more secure that digital data > behind any "security" code open to the world. There isn't a security system > out there that can't be hacked. If the client insists on keeping this > information online, then find another client because at some time, someone > is going to jail and it's not going to be me. > > So, let the people who can keep up with technology (a continued effort and > expense) worry about hackers -- just use their services and sleep at night. > > > Cheers, > > tedd > > > To add my two cents - if you plan to store card information, in the eyes of the Payment Card Industry you will have to be Tier One compliant. How high are the standards? Visit hackerguardian.com and take the free test. We *thought* it might be cool to store the CC info for a new enterprise, provide convenient "one-click" shopping, etc, so we ran through the questionnaire at that level. It would take more time to design, implement and test the security and audit systems than to write the app. Furthermore, since we were doing the new project in the cloud we could not meet the requirements for physical security. So we settled for Tier4 - we take the information as part of the transaction, https to CC processor, get an "OK" or "Not OK" back, and no cardholder info stored on our server at all, apart from the transaction number. Cheers - Miles Thompson ~~ "The piano keys are black and white, But they sound like a million colours in your mind" Spider's Web - Katie Melua
Re: [PHP] Credit Card encryption
At 12:43 PM +0200 5/30/10, Peter Lind wrote: On 30 May 2010 07:49, Paul M Foster wrote: -snip- Does anyone have a better solution? I'm sorry if the following sounds a bit harsh, but in matters like these I prefer blunt directness. A few notes. 1) one-way encryption means "no decrypting" - that's what one-way is (like a one-way street, there's no driving the other direction). You're looking for encryption that can be decrypted, not one-way encryption which is otherwise known as hashing. 2) do not store credit card information. Just don't. It's downright stupid to do so, because it's a huge risk for very little gain. 3) farm out risks like these to companies that specialize in dealing with them - you will with 100% certainty not be able to do as good a job as these. The question to ask is not: how to store credit card information securely? The question to ask is: do I really want to be the next person in the internet spotlight because my setup turned out to have a security hole I overlooked? Paul: Let me be equally blunt. Petter is absolutely right! Do NOT have your client store customer credit card information on a server -- period! That's the stuff people go to jail over. Instead, use a credit card clearing house to do the heavy work, that's what they get paid for. Besides, most credit card processing agencies even require that you use the customer's data (cc number, expiry date and CCS) to make the sale and then immediately dispose of it afterwards, usually within 24 hours under a signed agreement. Holding that information for more than 24 hours can be a criminal offense regardless of what type of hashing you use. While many of my customers have made the argument that they keep hard-copy records of their customer's credit-card information in-house and they don't understand why they can't do the same online -- I reply that hard-copy kept in a safe behind "brick and mortar" in far more secure that digital data behind any "security" code open to the world. There isn't a security system out there that can't be hacked. If the client insists on keeping this information online, then find another client because at some time, someone is going to jail and it's not going to be me. So, let the people who can keep up with technology (a continued effort and expense) worry about hackers -- just use their services and sleep at night. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
On 30 May 2010 07:49, Paul M Foster wrote: > This question is for people who take and store credit card information > for customers. > > Credit card companies, in an attempt to lessen fraud, are tightening the > screws on merchants who take credit cards. One aspect of this is a > requirement to store credit card information from customers encrypted. > > So let's say you have a customer whose credit card you keep on file, > because they'll be charging other items with you. The credit card > companies would like you to store this information with strong > encryption, which in their mind is one-way encryption. > > Now let's say that the credit card number is part of the customer > record. When looking at the customer record, you see just the last four > digits of the card. But when editing the record or when printing out > reports of things which must be charged, you will see the whole number. > Assume the users of the system have logins and passwords. > > Now if you one-way encrypt the credit card numbers in the customer > records, then it seems to me that any time that field has to be accessed > (to edit the record or charge something to the card), you'd have to have > the user enter a specific "password" to unlock the encryption. This > would be quite in addition to their username and password. Moreover for > this to be as secure as the credit card companies would like it, > whatever "password" is used would need to be changed frequently, > particularly at any change of personnel. This means you'd have to > re-encrypt all the credit card numbers using the new "password" every > few months or when you fire someone who had access to the data. > > This seems like an excessively cumbersome solution. Is this seriously > the way it's done? Does anyone have a better solution? > I'm sorry if the following sounds a bit harsh, but in matters like these I prefer blunt directness. A few notes. 1) one-way encryption means "no decrypting" - that's what one-way is (like a one-way street, there's no driving the other direction). You're looking for encryption that can be decrypted, not one-way encryption which is otherwise known as hashing. 2) do not store credit card information. Just don't. It's downright stupid to do so, because it's a huge risk for very little gain. 3) farm out risks like these to companies that specialize in dealing with them - you will with 100% certainty not be able to do as good a job as these. The question to ask is not: how to store credit card information securely? The question to ask is: do I really want to be the next person in the internet spotlight because my setup turned out to have a security hole I overlooked? Regards Peter -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Credit Card encryption
On Sun, May 30, 2010 at 2:16 AM, Ashley Sheridan wrote: > On Sun, 2010-05-30 at 01:49 -0400, Paul M Foster wrote: > > > This question is for people who take and store credit card information > > for customers. > > > > Credit card companies, in an attempt to lessen fraud, are tightening the > > screws on merchants who take credit cards. One aspect of this is a > > requirement to store credit card information from customers encrypted. > > > > So let's say you have a customer whose credit card you keep on file, > > because they'll be charging other items with you. The credit card > > companies would like you to store this information with strong > > encryption, which in their mind is one-way encryption. > > > > Now let's say that the credit card number is part of the customer > > record. When looking at the customer record, you see just the last four > > digits of the card. But when editing the record or when printing out > > reports of things which must be charged, you will see the whole number. > > Assume the users of the system have logins and passwords. > > > > Now if you one-way encrypt the credit card numbers in the customer > > records, then it seems to me that any time that field has to be accessed > > (to edit the record or charge something to the card), you'd have to have > > the user enter a specific "password" to unlock the encryption. This > > would be quite in addition to their username and password. Moreover for > > this to be as secure as the credit card companies would like it, > > whatever "password" is used would need to be changed frequently, > > particularly at any change of personnel. This means you'd have to > > re-encrypt all the credit card numbers using the new "password" every > > few months or when you fire someone who had access to the data. > > > > This seems like an excessively cumbersome solution. Is this seriously > > the way it's done? Does anyone have a better solution? > > > > > > Paul > > > > -- > > Paul M. Foster > > > > > It's not just a matter of encrypting the credit card details. You also > have to ensure the server meets specific security requirements, every > last little bit of software has to be updated and patched. There are > services that will check your server out for you (last one I used was > McAffee Secure) I am certain that this is a legal requirement in order > to allow you to process credit card details. > > You won't have to encrypt the password against the username of whoever > has access to it. Just encrypt it the once, and use the DBMS side of > things to manage access rights. Maybe use a couple of fields in the DB > to store the credit card number in two versions, one that is two-way > encrypted, the second that is one-way. You can set up your web system to > only have access to the one-way version, meaning that the actual number > can't be got by that user. The two-way encrypted version would be > accessible only by a specific second DB user, the access details of > which could change when personnel changes. > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > > Hi Paul, When you describe one-way or two-way encryption, what are you describing? Are you describing hashing vs encryption where the plain-text is recoverable with a key, or are you describing symmetric (one key handles encrypting and decrypting) vs asymmetric (separate keys handle encrypting and decrypting) encryption? Now if you one-way encrypt the credit card numbers in the customer records, then it seems to me that any time that field has to be accessed (to edit the record or charge something to the card), you'd have to have the user enter a specific "password" to unlock the encryption. You can't decrypt (or "unlock") a hashed password (at least if you used a secure hash), but I'm not sure you're talking about symmetric vs asymmetric encryption, either. With more details , I can provide feedback on the encryption schemes you're considering (remember, you have to make sure that you are managing encryption keys very carefully, as among other things, PCI requires that "keys are stored in encrypted format and that key- encrypting keys are stored separately from data- encrypting keys.") However, I'd strongly recommend letting a payment gateway do the heavy lifting. You let the payment gateway store the credit card details, and when you want to process another transaction for a visitor, you use the id for the visitor that's stored in your DB (if they already have set up an account) to process the request. For example, this type of scheme is documented at Rackspace (PDF): http://cloudsites.rackspacecloud.com/index.php/Can_I_host_a_PCI_compliant_site_on_Cloud_Sites%3F Adam -- Nephtali: PHP web framework that functions beautifully http://nephtaliproject.com
Re: [PHP] Credit Card encryption
On Sun, 2010-05-30 at 01:49 -0400, Paul M Foster wrote: > This question is for people who take and store credit card information > for customers. > > Credit card companies, in an attempt to lessen fraud, are tightening the > screws on merchants who take credit cards. One aspect of this is a > requirement to store credit card information from customers encrypted. > > So let's say you have a customer whose credit card you keep on file, > because they'll be charging other items with you. The credit card > companies would like you to store this information with strong > encryption, which in their mind is one-way encryption. > > Now let's say that the credit card number is part of the customer > record. When looking at the customer record, you see just the last four > digits of the card. But when editing the record or when printing out > reports of things which must be charged, you will see the whole number. > Assume the users of the system have logins and passwords. > > Now if you one-way encrypt the credit card numbers in the customer > records, then it seems to me that any time that field has to be accessed > (to edit the record or charge something to the card), you'd have to have > the user enter a specific "password" to unlock the encryption. This > would be quite in addition to their username and password. Moreover for > this to be as secure as the credit card companies would like it, > whatever "password" is used would need to be changed frequently, > particularly at any change of personnel. This means you'd have to > re-encrypt all the credit card numbers using the new "password" every > few months or when you fire someone who had access to the data. > > This seems like an excessively cumbersome solution. Is this seriously > the way it's done? Does anyone have a better solution? > > > Paul > > -- > Paul M. Foster > It's not just a matter of encrypting the credit card details. You also have to ensure the server meets specific security requirements, every last little bit of software has to be updated and patched. There are services that will check your server out for you (last one I used was McAffee Secure) I am certain that this is a legal requirement in order to allow you to process credit card details. You won't have to encrypt the password against the username of whoever has access to it. Just encrypt it the once, and use the DBMS side of things to manage access rights. Maybe use a couple of fields in the DB to store the credit card number in two versions, one that is two-way encrypted, the second that is one-way. You can set up your web system to only have access to the one-way version, meaning that the actual number can't be got by that user. The two-way encrypted version would be accessible only by a specific second DB user, the access details of which could change when personnel changes. Thanks, Ash http://www.ashleysheridan.co.uk
[PHP] Credit Card encryption
This question is for people who take and store credit card information for customers. Credit card companies, in an attempt to lessen fraud, are tightening the screws on merchants who take credit cards. One aspect of this is a requirement to store credit card information from customers encrypted. So let's say you have a customer whose credit card you keep on file, because they'll be charging other items with you. The credit card companies would like you to store this information with strong encryption, which in their mind is one-way encryption. Now let's say that the credit card number is part of the customer record. When looking at the customer record, you see just the last four digits of the card. But when editing the record or when printing out reports of things which must be charged, you will see the whole number. Assume the users of the system have logins and passwords. Now if you one-way encrypt the credit card numbers in the customer records, then it seems to me that any time that field has to be accessed (to edit the record or charge something to the card), you'd have to have the user enter a specific "password" to unlock the encryption. This would be quite in addition to their username and password. Moreover for this to be as secure as the credit card companies would like it, whatever "password" is used would need to be changed frequently, particularly at any change of personnel. This means you'd have to re-encrypt all the credit card numbers using the new "password" every few months or when you fire someone who had access to the data. This seems like an excessively cumbersome solution. Is this seriously the way it's done? Does anyone have a better solution? Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
