Keep Your Stuff Safe: What Every Church Needs to Know about Safe & Secure Commerce (part 1 of 3)Posted at November 28, 2011
In case you weren’t aware, church staff training (or seminary) doesn’t normally include curriculum on how to create secure Internet transactions. Yet in an age when most churches are venturing into the world of online giving or other types of eCommerce, the topic is suddenly very relevant to effective ministry.
Simply put: if you conduct online commerce insecurely, you may be doing more harm to your parishioners than good.
Our Care Team is often asked about SSL certificates, eCommerce (specifically merchant processing), and PCI Compliance. In the next few posts I will answer the basic questions about each one and why they are important to our customers and Internet users in general.
Before I dive in, let me get some housekeeping out of the way. These three topics are very complicated and messy when you get deep into them. I’m going to attempt to explain it in a way everyone can understand, not just you geeks out there. This is not meant to be an exhaustive explanation of how it works technically.
Let’s set the stage with a little scenario. Close your eyes and think about driving to the grocery store. How many intersections do you go through to get there? How many turns do you make? How many traffic cameras can see your license plate on the way? I say this to scare you, just to give you a good idea of what can happen with data as it travels over the public “streets” of the internet. At any point it can be observed most commonly by malware or spyware. A traffic camera observing your license plate isn’t a huge deal, but what if your credit card information, bank account information, or Social Security Number was painted on the side of your car? Do I have your attention? We’ll come back to our scenario in a bit, but first let’s cover some definitions.
i. Certificate Authority (CA) – an organization trusted to provide secure public keys otherwise known as SSL Certificates.
ii. Private key – used to decrypt or “unlock” data that has been encrypted or “locked” by the public key. You could think of it as a master or skeleton key.
iii. Certificate Signing Request (CSR) –a file given to a Certificate Authority (CA) to generate a public key.
iv. SSL Certificate or Public Key – a key used to encrypt data (credit card number, expiration date, security code, name, address, etc)
Setting up, configuring or installing an SSL certificate is a process, and usually will involve both you and your webhost. As this is a high level overview, the process for each type of web server (IIS, Apache, etc) can vary slightly. If your website is hosted by an outside organization, they should first ask you for some information, such as your domain name, where your business or church is located (city and state) and maybe a few other things like which department within your organization will be using the certificate. Based on the information you provide, your web host will generate a Private Key. This key should be protected at all costs and most server software handles this protection automatically. This is critical since as I mentioned in my definition, this key unlocks anything locked by the public key. It is the “key to the castle” or the “master key”.
A CSR is then created using the private key. This CSR is sent to a Certificate Authority and in turn your SSL certificate is generated. You then send your SSL certificate to your webhost for installation.
Now you may be thinking, if I’m sending these things around to all of these organizations; how is this secure? The CSR and the SSL Certificate are allowed to be in the public realm. This is what makes SSL encryption effective for eCommerce over the web. The only information exchanged publically are allowed to be public. It doesn’t matter who has them since the only thing that can decrypt or unlock data encrypted by the public key is the private key.
Once the SSL certificate is installed, any communications between a browser and the web server is encrypted SO LONG AS the browser requested a secure connection or in other words is using HTTPS in front of the URL in the address bar.
This is where things really get cool, recall our scenario of driving to the grocery store. In a non secure situation (take a “contact us” form on your website for example) data sent from your browser to the server is sent in “plain text” or “in the clear”. This means that someone, or more commonly something (spyware or malware), can observe the data as it travels between your computer and the server just like a traffic camera observes your car. When you use SSL to lock the data up, it is like you putting your credit card in your wallet, putting your wallet inside the glove box and locking the doors. The chances of that traffic camera seeing your credit card number is now very, very small.
When creating forms on the web, it is important to ask yourself, if I was a visitor filling out this form, would I want to provide this information to this website? If the form is asking for sensitive information, is it using SSL encryption? What happens to this data after I press the submit button?
I’ll be answering the last question next time. Stay tuned for how we at SiteOrganic ensure the credit card information gets from the web server to the bank in a secure way.
If you’d like more information on SSL Encryption, there are TONS of resources available on the net, way too many to list. Searching Bing for “how does SSL work” returned over 27 million results and Google returned 54 million. If you have specific implementation questions for how we at SiteOrganic secure websites, leave us a comment or contact our Care Team.
By Chuck Boyer
Director of Development & Production