Tuesday, October 25, 2011

Securing a Church Website

When I wrote Church Website Design: A step-by-step approach, one of the topics I didn't cover was that of a secure website. Since my primary focus was people who were new to church website development, I tried to walk the straighter path. Most churches don't need a secure website because most churches are providing nothing but publicly available information. When all you are doing is providing information like when your church meets, what programs you have, what events are on the calendar, etc. it doesn't make sense to pay the extra money required for a secure website. But that's not to say that no church ever needs a secure website. I am currently in the process of implementing a secure website for our church.

You may be wondering why a church needs a secure website. I our case, it is because we want a means for our Awana staff to access certain information about our clubbers through the Internet. None of it is financial in nature and it is doubtful that anything would happen other than a few families would get more junk mail and SPAM if the information got in the wrong hands, but since children are involved, we don't want to assume anything. We want to keep the information out of the hands of all but people we trust. And by that, I mean our Awana staff, who we know because they are members of our church and because they all go through a background check before we allow them to take on that responsibility. If someone unsavory does gain access to that information, we don't want it to be from our lack of effort.

Once we've identified each person who is to have access to the data, the data is protected by an SSL certificate. That works like this: A trusted person sits down at his browser and attempts to access the website. With some handshaking, the browser determines if it trusts the server. Essentially, it verifies that the server IP address matches the certificate. Once that is done, the server and the browser communicate via encrypted messages. The certificate provides the server's public key.

None of this is of any importance unless your website requires the user login. Anyone can access a "secure" website that doesn't have a password, so the fact that the messages between the sites can't be decoded is of little importance. To secure the website, you need to redirect attempts to access the website through HTTP to the HTTPS connection. And you need a login form as the first screen of the HTTPS site. Because that screen is part of the secure site, the data sent from the form will be encrypted. From a practical standpoint, what this means is that when the server authenticates the password, we can assume that it came from the browser that initiated the session. Because the browser was able to provide a valid userid and password, someone who had knowledge of the userid and password had to type it into the form.

All of that is dependent on us implementing the website without inadvertantly creating a backdoor. That means that every trusted page must check for a valid userid and password, either by making the check each time or by means of a session flag that is set by the page that follows the login screen. It also means that we don't allow the user to enter a password into an unsecured form. Another thing to avoid is allowing the unsecured portion of the site to access any of the secured portion other than a link to the secured login screen. The simpliest of coding mistakes could provide access to more data than we intended.

Most churches will never need a secure website because they are trying to share more information, not hide it away. But when personal information is involved, a secure website may be needed.