Credit Card encryption
in [General]
|
From: tedd on 1 Jun 2010 10:40 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
From: tedd on 1 Jun 2010 10:53 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
From: Paul M Foster on 1 Jun 2010 11:14 On Tue, Jun 01, 2010 at 04:17:21PM +0200, Peter Lind wrote: > On 1 June 2010 15:58, Paul M Foster <paulf(a)quillandmouse.com> 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
From: Paul M Foster on 1 Jun 2010 11:15 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
From: Brandon Rampersad on 1 Jun 2010 22:17
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 <paulf(a)quillandmouse.com>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 |