Re: [PHP] Encryption Advice
On Sat, May 20, 2006 10:35 am, Lawrence Kennon wrote: --- Rory Browne [EMAIL PROTECTED] wrote: but does support Cardservice International. These guys give you a PHP library that you http://php.net/include which then provides functions you can call which you pass in the CC# and they give you back a success/failure code and a Transaction number. You never have to visit their URL or anything like that in the process. Or, even easier, install something like osCommerce or ZenCart of any of the zillion shopping carts and they'll have a plug-in for Cardservice International, and you don't have to do much more than install and configure the damn thing. -- 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] Encryption Advice
--- Rory Browne [EMAIL PROTECTED] wrote: It's better if, when it comes to time to checkout, you redirect your client to your Payment Service Providers (PSP's) website, your PSP processes the payment, and redirects the client back to your site. The PSP would then contact you directly to confirm the payment. That way there is no CC info on your server for you to protect. I really appreciate all the advice people have given. So the following questions are designed to try to fully understand the scenario and what the customer sees from their viewpoint. The site that I am trying to fix is absolutely awful right now. It is certainly not a high volume site, although I do think if properly designed it could do a lot more business than it does. It is the site of a self-published author and I think most people who buy his books go to Amazon to buy them because the shopping cart is so bad (he did it himself years ago, and he is not any kind of web designer or programmer). The site uses the Hassan Shopping Cart which is a Perl script. Looking at the script it appears that it can support some sort of credit card authorization. But the way he has it set up now it just writes each order to a plain text file in a secure subdirectory (obviously a very bad idea) and sends him an email that tells him he has an order on the site to process. His hosting site is discontinuing support for the Hassan Shopping Cart, but does support Cardservice International. So let's say that I want to integrate a shopping cart with a PSP, right up to the moment they get to the checkout, they see my client's URL. They hit the Checkout button and then they will see the URL of the PSP? Then once they place the order then they are redirected back to my client's site and see that URL again? Is that an accurate description of how it works? Do you normally have control over the look and feel of how the checkout looks on the PSP site? Excuse me if these are really basic questions, but I haven't done this before. :) Thanks again, Lawrence Kennon __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Encryption Advice
snip So let's say that I want to integrate a shopping cart with a PSP, right up to the moment they get to the checkout, they see my client's URL. They hit the Checkout button and then they will see the URL of the PSP? Then once they place the order then they are redirected back to my client's site and see that URL again? Is that an accurate description of how it works? Do you normally have control over the look and feel of how the checkout looks on the PSP site? /snip Hi Lawrence, The way you explain it is the way that most of the Payment Service providers seem to work. However - depending on the PSP you use will depend on how much of the look and feel you can change. PayPal for example only allows very basic styling, whereas something like WorldPay (not sure if they are UK only) allows you to create templates, so other than the URL the change is seamless. The PSP will send you an email with the order details, and additionally most can post back to a script on your server with the details of the transaction - i.e. did it work? What was the total amount/currency? Etc. You can then use this to validate it's the correct transaction and send your own email/receipt/picking list accordingly. I've worked on a couple of these so if I can be of any help give me a shout. Cheers, Kev -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption Advice
On 5/19/06, Lawrence Kennon [EMAIL PROTECTED] wrote: For an ecommerce site where sensitive data is stored either in files, or in a database, have you used some form of encryption to protect your customer's data? I have a client who currently uses a Perl scripted shopping cart that stores orders (including credit card numbers) in plain text files on a shared server. The security of these files depends purely on the user/file system security measures enforced by the hosting company (which I think is a reasonably good company, but still I don't see it as being sufficiently secure). I am going to rewrite the shopping cart using PHP and was looking into ways to protect the data. Using GNU Privacy Guard (gpg) seemed like the ideal method because I could store the client's public key on the server to encrypt orders and the customer could then download the encrypted files and decrypt them on his PC with his private key (the client manually submits orders through his store front merchant account). I know this is a somewhat archaic procedure but it works sufficiently well for this client. However the hosting company won't support gpg so that leaves me with PHP mcrypt functions which I think would work very well, except for on thing - how to protect the secret key which now has to be on the server? Any ideas/suggestions/experience along that line? Thanks in advance, Lawrence Kennon Lawrence, from the very start, if you're on a shared-server, security is going to be compromised to a large degree. Hopefully your server at least uses suexec or suphp to prevent other people's scripts reading your data. If not, i'd say look for a new host immediately. As for your private key. Step 1 is to definitely keep it outside your doc_root, Step 2 is to give it really restrictive permissions like 400 or 600. I'm not entirely sure how much you can really do above that on a shared server. If you can convince your clients that security is a top-priority on this project, talk about getting a dedicated box so that your first-level of defense is simply nobody else is on the box, then you can worry a little bit less about your private key being stolen. -- Scott Hurring [scott dot hurring dot lists at gmail dot com] http://hurring.com/
RE: [PHP] Encryption Advice
For an ecommerce site where sensitive data is stored either in files, or in a database, have you used some form of encryption to protect your customer's data? I have a client who currently uses a Perl scripted shopping cart that stores orders (including credit card numbers) in plain text files on a shared server. I assume you want to be able to unencrypt the credit card number for later use, so a 1 way encryption method will not suffice. In that case, I don't know of a way to securly store this data in the environment you describe. If someone gained access to you data, they would also likely have access to your code and could therefore figure out how to unencrypt it. That said, my first piece of advice: Never, ever store credit card numbers. You are opening yourself up to a huge world of hurt by doing so. Unless you can come up with a reason (you probably can't) that you absolutely MUST store credit card numbers on a shared server, don't do it. The security of these files depends purely on the user/file system security measures enforced by the hosting company (which I think is a reasonably good company, but still I don't see it as being sufficiently secure). You are willing to risk bazillion dollar lawsuits on the sufficiently secure file permissions of a reasonably good company? I would suggest, at minimum, getting a dedicated box with a well-known hosting company if you are going to store credit card numbers. At least then, you can enforce you own security policies, and be reasonably sure you are the only one digging around on the box. I am going to rewrite the shopping cart using PHP and was looking into ways to protect the data. Using GNU Privacy Guard (gpg) seemed like the ideal method because I could store the client's public key on the server to encrypt orders and the customer could then download the encrypted files and decrypt them on his PC with his private key (the client manually submits orders through his store front merchant account). I know this is a somewhat archaic procedure but it works sufficiently well for this client. If you are going to rewrite the shopping cart application, why not look into some ready-made ones. http://www.oscommerce.com , a complete, free online store, comes to mind immediately. There are many others. Search the archives of this list if you're interested. Why reinvent the wheel? :) However the hosting company won't support gpg so that leaves me with PHP mcrypt functions which I think would work very well, except for on thing - how to protect the secret key which now has to be on the server? On a shared server, you can't really protect it, but you can take some steps to make it as difficult to get as possible. Storing it outside of webroot and giving it restrictive permissions would be good first steps. You don't really go into much detail about your application. But, if you search the archives of this list for 'credit card', you will find some really compelling reasons NOT to ever store credit card numbers. If the reason you are doing so is purely for customer convienience, you should probably reevaluate that position. JM -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Encryption Advice
Re: Encryption Advice First off, thanks to the folks who replied with advice. I am mulling over your advice (and I greatly appreciate it!). I have been doing PHP programming for a couple years, including secure sites, but this is my first ecommerce venture, so I am trying to learn as much as I can. Also it is for a friend and I figure the learning is my payment. :) In regards to GNU Privacy Guard (gpg), I did actually manage to get that to work in the hosting environment (without the help of the hosting support folks! :). I use a directive to tell gpg to not warn me about using insecure memory but since no private keys reside on this host I think I can safely ignore that (they can't steal what is not there). The real difficulty is that the httpd process runs as an id different than my logon account and I have no shell access. What I did to get around that was to create a subdirectory .gnupg from my html root and ftp'd my pubring.gpg (public key ring) and trustdb.gpg (trust database) into that subdirectory. I secured that wide open (after all, it is a _public_ keyring) cause otherwise gpg will fail. Then I coded the php program to send a command like this using shell_exec: /usr/bin/gpg -a -e -r 'mykeyname' --no-default-keyring --keyring /home/users/web/myhome/.gnupg/pubring.gpg --no-secmem-warning /home/users/web/myhome/ayres In the above the last file ayres is the file to encode and the result of the above is a file ayres.asc which is encoded and ready to be mailed. I used the --no-default-keyring and --keyring to point gpg to the keyrings I ftp'd up to the .gnupg subdirectory. Anyway that worked, and on downloading the encoded file I could decode it with the secret key. Don't know if I will use this approach yet, but it was fun to figure out that it could be done! :) Thanks to all who gave advice! Again, I will give some thought to that, and I very much appreciate advice from people who have been there, done that! Lawrence Kennon __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption Advice
Lawrence Kennon wrote: I use a directive to tell gpg to not warn me about using insecure memory but since no private keys reside on this host I think I can safely ignore that (they can't steal what is not there). But your unencrypted data is there, so someone could possibly snoop that from the insecure memory. Gr, Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption Advice
--- Koen Martens [EMAIL PROTECTED] wrote: But your unencrypted data is there, so someone could possibly snoop that from the insecure memory. This is true. I am going to ask the hosting company to setuid gpg as root. That should solve one problem (from gpg docs): This is necessary to lock memory pages. Locking memory pages prevents the operating system from writing them to disk and thereby keeping your secret keys really secret. But just out of curiousity, let's assume you are running a shopping cart which takes credit cards and passes them on to whomever approves them and you don't _ever_ write this info to files. Aren't you also vulnerable to someone being able to snoop memory on your process for sensitive information? I mean at some point some program on the server has to take the customer's credit card, and that info is in memory somewhere until you get the approval. Isn't that true? Thanks!, Lawrence Kennon __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Encryption Advice
--- Koen Martens [EMAIL PROTECTED] wrote: But your unencrypted data is there, so someone could possibly snoop that from the insecure memory. This is true. I am going to ask the hosting company to setuid gpg as root. That should solve one problem (from gpg docs): This is necessary to lock memory pages. Locking memory pages prevents the operating system from writing them to disk and thereby keeping your secret keys really secret. But just out of curiousity, let's assume you are running a shopping cart which takes credit cards and passes them on to whomever approves them and you don't _ever_ write this info to files. Aren't you also vulnerable to someone being able to snoop memory on your process for sensitive information? I mean at some point some program on the server has to take the customer's credit card, and that info is in memory somewhere until you get the approval. Isn't that true? Im my case, I use a third party service that handles credit card payments. I take the order, and pass the order amount to the credit card processing service. THEY take the credit card info into THEIR system, process the payment, then send the customer back to my site. I never take credit card info. So, if somebody steals my customers identity, I am absolved of any responsibility. JM -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption Advice
On Fri, May 19, 2006 8:54 am, Lawrence Kennon wrote: For an ecommerce site where sensitive data is stored either in files, or in a database, have you used some form of encryption to protect your customer's data? I have a client who currently uses a Perl scripted shopping cart that stores orders (including credit card numbers) in plain text files on a shared server. The security of these files depends purely on the user/file system security measures enforced by the hosting company (which I think is a reasonably good company, but still I don't see it as being sufficiently secure). DO NOT STORE CREDIT CARD NUMBERS!!! Period!!! If your PHP script can access them, then they are too accessible to the Bad Guys. It's that simple. I am going to rewrite the shopping cart using PHP and was looking into ways to protect the data. Using GNU Privacy Guard (gpg) seemed like the ideal method because I could store the client's public key on the server to encrypt orders and the customer could then download the encrypted files and decrypt them on his PC with his private key (the client manually submits orders through his store front merchant account). I know this is a somewhat archaic procedure but it works sufficiently well for this client. Just get a friggin' online merchant account, and process the orders in realtime. It's just not that expensive, and will save your client HUGE MONSTROUS amounts of risk. You can set up a recurring charge if you think you need the CC# for that -- and then you get a Tx # from the merch and you do NOT need the CC#. However the hosting company won't support gpg so that leaves me with PHP mcrypt functions which I think would work very well, except for on thing - how to protect the secret key which now has to be on the server? It does? Look, if you absolutely insist doing this the wrong way, AT LEAST make the client upload the key for decrypting and then ERASE the key immediately -- Or better, make him paste it into a big ol' textbox on an https server, and never have it hit the hard drive at all. Any ideas/suggestions/experience along that line? Years ago, I was gonna do what you propose, because my client was too cheap to get a cert and pay the online merch fees. Thank GOD people on this list stopped me. Remember that game hot potato as a kid? CC#s are hot potatos. Get it, process it, nuke it. Fast! -- 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] Encryption Advice
On Fri, May 19, 2006 1:36 pm, Lawrence Kennon wrote: In regards to GNU Privacy Guard (gpg), I did actually manage to get that to work in the hosting environment (without the help of the hosting support folks! :). I use a directive to tell gpg to not warn me about using insecure memory but since no private keys reside on this host I think I can safely ignore that (they can't steal what is not there). I think the concern here is that the CC#s in *RAM* are susceptible to other users' snooping them. Your data will be in RAM, and you ARE at risk. -- 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] Encryption Advice
On Fri, May 19, 2006 3:00 pm, Lawrence Kennon wrote: But just out of curiousity, let's assume you are running a shopping cart which takes credit cards and passes them on to whomever approves them and you don't _ever_ write this info to files. Aren't you also vulnerable to someone being able to snoop memory on your process for sensitive information? I mean at some point some program on the server has to take the customer's credit card, and that info is in memory somewhere until you get the approval. Isn't that true? Yes, and it's worse than that. See, if your server gets busy, then those chunks of RAM *will* get paged out to hard drive. And, in theory, users can read that hard drive data not only during the transaction, but long after, until RAM has a page-fault again and wipes it out. So now you've got *TWO* potential holes in your armor. Throw your gpg into the mix, and you've got even more, including: #1. gpg insecure RAM, unless your host change bit for you #2. The data you pass from PHP to gpg through exec is visible to a 'ps' command, if it's timed right, or run often enough, fast enough, to catch it. A quick hack shell script will pretty much catch ALL your CC#s as long as it runs #3. gpg itself may get page-faulted to disk (this may be a duplicate of #1 -- I'm NOT an expert) Bottom line is, as a beginner in this realm, you REALLY should not be trying to do what you are trying to do. You NEED to go to your client and explain the following facts: *IF* their data is every compromised, they are required BY LAW to contact EVERY customer and tell them: Sorry, we just gave away your credit card number to some crooks. Have a nice day. Then describe all the ways (above) that the data is at risk. PLUS, let's look at the store-front end of things. Is the PC locked in a secure location? Or is it just in some office somewhere? How hard would it be for a Bad Guy to get ahold of the PC long enough to hack it to catch keystrokes and snag the private key? Is it behind a firewall? With up-to-date virus-protection? And it's not used for normal web-surfing, right? Cuz, right there, you're just BEGGING some Bad Guy to install mal-ware that will snoop on your private key. Are there any employees who have access to this PC? What sort of background checks have you run on every employee? Do you REALLY want to run the risk of having to DESTROY your reputation with all your customers? -- 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] Encryption Advice
snip lots of good stuff Are there any employees who have access to this PC? What sort of background checks have you run on every employee? Do you REALLY want to run the risk of having to DESTROY your reputation with all your customers? /snip Not only all that, but suppose one of your customers has his CC info stolen somewhere else, not even on your site. He reports it to the CC company, and they investigate. They're going to ask him where he used his card online. Your site pops up. The CC company contacts you and asks you to describe what you do to protect their customer's CC numbers. You say 'I wrote an encryption routine that I think is pretty good...' :-/ So, even if your site is bulletproof, you are going to have to be ready to back up your claim that the data is safe. The first question an investigator is going to ask is Where is the data stored?. Your answer? A shared server at some hosting company. :-/ The good news is, there is no reason to handle credit cards in an online store. There are tons of third party processors that will take on all these risks for you. JM -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption Advice
DO NOT STORE CREDIT CARD NUMBERS!!! Period!!! If your PHP script can access them, then they are too accessible to the Bad Guys. Ditto Even if nothing else, someone could modify your code to email them the CC Numbers. It's better if, when it comes to time to checkout, you redirect your client to your Payment Service Providers (PSP's) website, your PSP processes the payment, and redirects the client back to your site. The PSP would then contact you directly to confirm the payment. That way there is no CC info on your server for you to protect. Unless you are a computer security professional and _REALLY_ know what you're doing.
