I am trying to integrate PHP-PayPal-IPN (great library btw, you can see the blog post on usage here).
Since security is essential here, I have checked the source code. I found no apparent problems with it, but I would also like to check the PayPal certificate chain that is bundled with the library: https://github.com/Quixotix/PHP-PayPal-IPN/tree/master/cert
How can I check that the certificate chain is correct? (correct == "it allows only connections from PayPal and from nowhere else")
I don't think that's the point of it. That SSL just allows you to setup your IPN script on a secure server so that the data is encrypted. To my knowledge it's not going to block hits to the script that don't come from PayPal's server.
That's where the verified/unverified check comes into play. If the data comes from anywhere other than PayPal it will fall into the unverified portion of code. You can choose to handle these however you want. Completely ignore them, log them as invalid but keep them for your records, send yourself email notifications, etc.
Related
I currently use only payment buttons, and an IPN php script I got from https://github.com/paypal/ipn-code-samples that is dated Nov 10, 2014.
My script simply posts back to www.paypal.com without encryption.
Is encryption becoming mandatory ?
Your IPN listener will be responsible to recieve PayPal call-backs and POST them to PayPal for verification. On that point, connection between your server to PayPal endpoint will need encryption with SHA-2.
So literally yes, you would need to check your server key store / trust store and make sure it includes SHA-2 compatible certs.
You may refer to this PayPal microsite for detailed instructions, these information are open to merchants seeing any impact
You have to verify that your Server supports SHA-2 (SHA-256). Use of SSL with SHA-2 would be manditory.
Since Chrome is deprecating support for SHA-1 by the end of 2015, all PayPal support for SHA-1 will be deprecated by the end of 2016.
You can test your server compatibility here shaaa..
PayPal sandbox environment is supporting SHA2(SHA-256) only. You may make test in below link (need to login with your Live credential) to check if your server could deal with the upgrade now.
https://developer.paypal.com/developer/ipnSimulator/
If the test passes, that means your server is able to deal with SHA-2 and you do not need to upgrade the certificate any more. If it fails, please contact your server provider to help you upgrade the SSL certificate.
Ok, so I have setup a Docusign Connect to a 3rd party application (Infusionsoft) and have it working great.
They don't natively work together, so I created a php script that reads the tabs in the docusign envelope, and passes it to Infusionsoft, along with a copy of the completed envelope itself.
Now I would like to pass payment info through this as well, as one of the document templates I have in Docusign is a billing agreement. I have done a test run of this with dummy info and I am able to do this well, BUT, I now have to be concerned with PCI compliance on this, right?
I have a dedicated server with a domain that has an SSL certificate which is hosting the php script, which does not store any information. It just passes the docusign info (gathered by using the docusign connect) and then formats it so it can be accepted by Infusionsoft.
I am a novice programmer, and pretty ignorant regarding knowledge behind encrypting data or securing a connection. The fact that Docusign passes the info through an XML file seems to be not ideal for handling sensitive data (at least I would imagine), and that is something that is out of my control.
So what I am asking is would it be possible to securely transmit payment info (credit card or bank account) through a Docusign connect connection in the type of setup I have? If so, how would I approach it? I am open to hiring a programmer if needed or getting a different server setup if it was necessary.
I can do this without adding the payment info to the template, and just adding it afterwards directly into Infusionsoft to limit my liability, but it would be so much easier if I could do it directly through Docusign Connect as it would automate the entire sign up process.
Well Comodo's test turned up a bunch of holes and warnings, with a detailed report of what to fix. I took that in turn to Hostgator support, who went ahead and made the appropriate changes to fix the holes. The also reported that their were a bunch of false positives with supporting documentation.
So I have to do another test to verify that everything was closed up and report the false positives. But other than that it seems like it should all be cleared up.
I also spoke with Docusign Support over the phone about this, and they confirmed other companies are doing what I am doing as well, which was reassuring.
So in short, use Comodos online scan tool to see what holes you have. Then contact your hosting company to fix the holes. Not a great answer, but I suppose better than nothing.
We don't store any credit card information. It is gathered via an HTML form, then processed by a PHP script which uses the API from Intuit to charge the credit card. After calling the API to charge the card, all credit card information is disposed of.
Here are my questions regarding the security of the credit card information:
I assume SSL is a must. Is this correct?
Should I switch from shared hosting to a dedicated server?
I assume there is no encryption that isn't easily un-reversible that can take
place between the HTML form and the PHP script, does any encryption
need to be used for what I'm trying to do?
If there is anything else you can think please share it. Thanks for your time everyone.
I assume SSL is a must. Is this correct?
Yes, correct.
Should I switch from shared
hosting to a dedicated server?
A VPS at minimum is a very good idea. You can probably not be PCI compliant successfully on a shared host, you just don't have enough control to lock your server down as required by PCI.
I assume there is no encryption that
isn't easily un-reversible that can take place between the HTML form
and the PHP script, does any encryption need to be used for what I'm
trying to do?
Your API should take care of that. Be sure the API is over an SSL/Secure connection as well.
Please read up on PCI requirements. You are transmitting cardholder data so you DO NEED TO BE PCI COMPLIANT. You will be at the "lowest level" of compliance (I think it's C or D). You will need to run quarterly scans on your server IP to prove compliance as well. As an FYI, I use McAffee Secure for this.
The only way you won't be subject to PCI rules is if the cardholder's data is entered on somebody else's server (think: paypal). Whenever you pay by paypal, you are transferred to PayPal's server, then transferred back. In that scheme, you would not need to be compliant.
Now a lot of the PCI requirements talk about some stuff that don't apply in the questionaire (i.e. is your server stored in a safe place, how physically secure is your building, etc....) - the good news is that your server/hosting company should handle that.
After your network scan, it'll come up with a list of things that make you non-compliant. They are almost always server related issues. You can either fix them yourself, or ask your host to help you - most hosts will do it if you send them the list. You will NOT be able to fix a lot of them on shared hosting.
Your points addressed in order
Yes, even when connecting to the API, which should be the only option
Its a good idea, less security exposure. You will have lower probability that a compromised tenant will compromise your site.
As long as you are not storing or caching the data in any form and using SSL for transit, you wont have to implement encryption on your application.
PCI requirements may be applicable.
1) I would serve the entire page through HTTPS to avoid users from getting the alarming message of "some resources are not protected"
2) Depends on the integration, if Intuit has provided you with an iframe or form action to use, then sensitive data never reaches your server. user either type and/or submit it directly to intuit with your page merely as a container.
If the above is true:
3) You don't have to pass PCI compliance. Intuit already did. Sensitive data never reaches your server, thus there's nothing to dispose.
4) Shared or dedicated host doesn't really matter since you are not transiting or storing any sensitive information.
SSL: Yes, of course. Between your server and the client, as well as between you and the API.
Dedicated Hosting: Ideally, yes. There are two problems with using shared hosting:
Anything stored in a session can potentially be retrieved by others on the server.
A security breach in a site that is not even yours could lead to a breach in yours.
These are primarily the domain of your host's security policies, and are not easily identified by PCI scans.
I am trying to get a full Kerberized domain environment configured, and one of the obstacles is webmail. I have scoured the Internet for information about how to do single sign on with Kerberos through webmail, but without definitive results. So now I am going to try and do it on my own.
The point is, while it is easy to authenticate against one service (the webmail frontend in this case) using mod_auth_kerb for Apache, forwarding a ticket to the IMAP/SMTP servers is proving more tricky. From the documentation about Kerberos that I have read it seems to be possible to accomplish this - The client would send a forwardable ticket to the webmail application, and then that server would use delegation to authenticate (as the user) to IMAP/SMTP. However, finding any actual information on existing implementations seems to be fruitless.
In attempting to make my own implementation, one of the first problems that I will face will be getting the ticket for use against the IMAP/SMTP servers. I can think of doing this one of two ways - either a forwardable ticket is stored at the point of authentication to the webmail, or whenever the user tries to send an email/refresh their mailboxes authentication occurs again, but this time no data is stored since it all occurs in one request (and mod_auth_kerb supports saving credentials for the duration of the request).
In going down the storing of credentials route, there are security concerns, scalability concerns and implementation concerns. However, authentication only happens once (whatever benefit that would give).
The reauthentication on refresh/send would be much more secure, since the credentials are only stored for the duration of the request due to mod_auth_kerb, and there should be fewer scalability issues since there will not be many credential caches floating around the place when many people are logged on. However, authentication would happen much more frequently, perhaps causing problems due to higher network load, or the chance that something bad would happen on the client between authenticating and attempting to send an email.
I am leaning towards the second method, simply because the security issues seem quite drastic, however I would like some more opinions - perhaps there is a better way of doing it?
EDIT: Another challenge which I will face is getting GSSAPI working with the PHP IMAP extension. From the material I have read it seems possible to do this one of two ways - either using Cyrus IMAP or using the built in GSSAPI mechanism in PHP IMAP. There is next to no documentation on how to do either method though, so help would be appreciated.
I'm doing a website with Realex as the payment gateway. I want to integrate remote realex payment method in my website.
I know when we go live we need SSL enabled on our website to do remote method payments. But my question is, Is SSL required when we are doing testing?
Every time I test, it results in error (remote method), but when I do Real Auth method there is no problem.
I don't know what the exact problem is. Am i missing something?
No. We use Realex, and don't use SSL on our test sites.
In fact, if we don't use SSL on our live sites, it still generates no error. Realex doesn't actually have any way to know whether or not you're using SSL.
As TRiG has already said, Realex have no way of telling whether or not you have SSL on your website. However, your customers will not feel safe entering card details if they don't see the little padlock, and this will affect your sales conversion.
Communications between your server and Realex are https/SSL, so this is secure, but the card data must first get from the browser to your server securely. You may prefer to use the Realex Redirect integration if you do not want to buy an SSL cert.
Owen
at merchant site in live / testing ssl is not required
it results in error . may be due to
your response URL is not set
or you are trying to get the response from local host
to set response URL have to contact Realex support ...
it is the same as we do in papal notify
what response URL we send that is to compare not to set