ChurchInsight  is now  
Hubb.church
 
 
 
 

Support for Hubb users

How can we help you today?

Customer Support > Security > How secure is my web site?

How secure is my web site?

Firstly, it's important to say that we take security extremely seriously. Brendan Neville, the founder & owner of Hubb.digital, the company who make Hubb.church, ran a financial services software company in the US before Hubb began. Approximately 50% of all banking transactions in the US during this period passed through software created by the company. Consequently, Hubb has been built from an understanding of the significance of security.

A few pieces of information which may be of interest to you regarding security...

All pages on your site and in the web office are transmitted securely using https. Certificates are generated for every hostname that point to our server on our system.

Passwords are encrypted and stored in the database via a 1way salted hash. This ensures that even if an attacker gained access to the database and the code, passwords cannot be stolen. In addition, different levels of password security can be selected by the organisation, relevant to their needs. e.g. These may force the user to create a password of a certain length and use numbers/characters not in the alphabet.

When a user requests a password reset, they will be sent a secure link by email which they can use to set their own password. This link will last for only a few hours (2 hours if they request it themselves, 24 hours if it's sent by an admin) and can only be used once.

Admins have the option to set up multi factor authentication for web office access.

The system is built on Microsoft .NET architecture with MS SQL Server as the database backend. Our servers are fully security patched up to date and are located in a secure data centre in London. These servers are accessed via VPN by the technical team. Administrator passwords are regularly changed, including at point of staff turnover.

We take security very seriously. We store the records of hundreds of thousands of users. The user database is common to all users, but code has been written to delineate between these and only allow the users/administrator(s) of a site to view the user data from their organisation.

Changes to the database are backed up in bulk and sent to a secondary server in the same location every 5 minutes. In the event of a severe problem resulting in the total failure of the database server, we would lose a maximum of 5 minutes worth of transactions on the database.

Backups are also sent to a second data centre in Manchester every 5 minutes. Offsite backups mean that if, for example, the UK server hosting company we use ceased trading or had a fire at their data centre we would still still have the bulk of our data to resume operations.

It's important to point out that where payment systems are in use by an organisation we do not store credit card numbers; these are all handled by third party payment processors so no such information could be accessed on our systems if there was ever a data breach.

Card details are handed straight to Stripe, a payment processing company who handle millions of payments every day and whose entire business depends on the security of the transactions they handle. No card details are seen, handled or stored by Hubb, or by the church. All of the elements on the payment page which handle sensitive data such as card numbers are in iframes hosted by Stripe themselves and so are secured by their own secure certificate and not subject to any communication with our servers.

Personal details that are stored on the web site can only be accessed by logging in using a unique user name and secure password. Even the contact details in the Address Book can only be accessed by a user who has the required level of involvement in your organisation (see the Address book guide for more details about setting your Address book policy). Full user details can only be accessed through the Web Office by those staff members who have been granted the required permissions.  

You can read about backups here.