User security and passwords

As a Company, our highest values are security, privacy and data protection. We work hard to ensure your data remains secure by adhering to industry best practices and standards. ChurchSuite features have privacy and security built in by design and our user login workflow is intentionally designed to deter unscrupulous attackers. In this article, we explain the key security features your Users will experience when logging into ChurchSuite and the optional security features you might consider using to help you and your team work more securely.

What we do to help your users work securely

• The Login workflow is designed to prevent exploits by not enumerating a user's identity and failed login reason—we don't separately confirm a valid username or an invalid password; the combination of username and password is authenticated together, which means someone unscrupulous can't determine if a username is valid.
• Password criteria (minimum 14 characters) don't enforce or require 'complex' passwords that are harder for humans to remember. Security best practice says, "Longer is stronger." Password methods, like Three Random Words, are widely considered more secure than a complex password comprising mixed-case characters, numbers, and special characters, which are found to create a cognitive overload for users who will typically make a more easily guessable password.
• When setting or resetting a password, we prevent the use of high-risk passwords by checking the password against a database of known compromised passwords.
• Users can further secure their ChurchSuite access with Multi-Factor Authentication, which means access to ChurchSuite is dependent on a code that can only be obtained from an authenticator app in their possession.
• Users will experience an enforced "wait" after four consecutive failed logins, which increases with each subsequent failed login.
• Google ReCaptcha is active on our login pages and activates after three failed login attempts. It requires the completion of a picture quiz and prevents automated login attempts by non-humans, like internet bots.
• Users will experience an enforced "wait" for consecutive "Forgotten password" requests within a short time. The "wait" increases with each consecutive reset request, up to one hour.
• Active browsing sessions expire after two hours of inactivity, and the user will be required to log in again.
• Active sessions are invalidated when a user resets their password, requiring the logged-in user to re-authenticate using the new password (browser only). App users typically remain logged in on a previously authenticated device, but they will be logged out and required to re-authenticate if the password reset request is made from an unrecognised IP address location.
• Sent password reset emails are logged in the user's sent communication log. Note that where a user email address is used for multiple user accounts, no password reset email is logged against a specific user.
• Helpful reports for Administrators are provided to help manage user security. The Password Security report has been designed to encourage user security best practices by giving insights into each user's password strength and the date their password was last changed. Changing passwords frequently is generally not considered more secure, but a weak password that hasn't been changed for a long time is less safe. The Logins report can be used to visualise User login activity, including successful and failed logins.

In addition to the above user protections, we have systems actively monitoring The Service across all customer accounts, which include automatic detection to protect against DoS attacks and brute force penetration attempts by automated bots. We also have protections before login requests reach a customer's account to guard against common exploits. We continually monitor service data requests for anomalies and errors and investigate these—we'll report issues identified to a customer account contact and add any mitigations that are needed.

What you can do to help your users work securely

• An Administrator can enforce Multi-Factor Authentication for all Users. Note this won't affect app users who are already authenticated. Still, if enabled, anyone next logging into ChurchSuite in a browser or app environment will be challenged to set up multi-factor authentication before they can proceed with logging in. Similarly, if multi-factor authentication is temporarily disabled for a user - perhaps if they've lost their authentication app device - they'll be required to set up multi-factor authentication when they next log in.
• For customers who use Microsoft Entra ID (formerly known as Azure Active Directory) or Google Workspace, you can give your users a Single Sign-On user experience by integrating those services with ChurchSuite. This means users can use their single sign-on credentials for those services to access ChurchSuite, which gives you greater control over user access from the Entra ID or Google administrator consoles.
• Do consider user email inbox security. Password reset emails and certain login-related notifications are sent to the user's inbox. A compromised email account could lead to someone unscrupulous accessing ChurchSuite via a password reset where multi-factor authentication is not in use. Remember, too, that personal email accounts are likely to fall outside your purview or ability to monitor or manage.
• Consider providing your users with security training or publishing some "secure working" guidance to identify possible complacency among competent users while bringing helpful information and reassurance to new or less competent users.