MFA Private Beta

Introduction

MFA or "Multi-Factor Authentication" is a security-enhancing practice of requiring a person to perform more than one step, beyond email and password, for example,  when logging into a system. ShulCloud offers two additional step options, plus the ability for admins to specify which of those options are available or required based on whether the person is an admin or non-admin. Both options require the person to enter a valid verification code in order to complete MFA and successfully log into ShulCloud. Other actions, such as a person resetting their password, also trigger MFA. Login and password related admin actions on non-admin accounts do not trigger MFA (such as log in as user).

Settings

How to review/edit MFA Settings

1. Choose Settings from an admin menu (requirements Settings permission)
2. Choose Edit MFA Settings

MFA Settings Overview

In the MFA for Admins and MFA for Non-Admins settings sections, you specify two settings: 

• Required (yes/no) -  whether use of MFA is mandatory for that category of users.
• Modes allowed - how verification codes are obtained (email and/or authenticator app).

NOTE: after an introductory period, ShulCloud will require MFA for Admins across the platform.

In Other Settings, you specify three additional settings that apply to admins and non-admins alike:

• Remember Me Duration (hours) - how long a person who has completed MFA can log in again from the same device without completing MFA again. This setting can work in concert with "Timeout Sessions" setting in the Security area of the main Settings page (it automatically logs users out after a period of time). For example, you could log people out automatically daily and require MFA for logging back in only weekly, if from the same device.
  
  
  • For the greatest security, leave blank or enter 0 to disable remembering devices.
  • For medium security, enter a number from 8-24.
  • For the least security, enter a number greater than 24 (e.g.  720 to require MFA again after 30 days). 
    
    
• Code Expiration (minutes) - how long a person authenticating via email has to enter the code sent to their email. If the code expires, the person can request a new code. This setting does not apply to people authenticating using an authenticator app (those codes re-generate automatically). 
  
  
• Help Text - the text you enter here is shown on the code entry screen and in verification code emails to instruct people what to do if they are having problems logging in using MFA.

Actions Triggering MFA

A person required to complete MFA triggers it by ...

• Initiating logging in, by providing a valid email address and password, from a device not remembered for MFA purposes.
  
  
• Initiating a password reset process and then providing a valid email address and password.
  
  
• Clicking a login in link on a device not remembered for MFA purposes.

Standard MFA Workflows

The central difference between completing MFA by email or by authenticator app is from where the person obtains the verification they must enter.

Email

1. The person provides a valid email address and password.
2. The system emails the person a verification code and displays a code entry screen.
3. The person enters the verification code.
4. The system completes login, prompting for a new password if that is what triggered MFA.

• If the code expires, person clicks "Re-Send Code" link.
• Ask covered below, it is possible for a device to be "remembered" for a period of time, eliminating the need to complete MFA again to complete logging in.

Above: Body of email sent to the person logging in. Expiration time and help text are from MFA Settings.

Above: Code entry screen. Help text is from MFA Settings.

Authenticator App

1. The person provides a valid email address and password.
2. The system displays a code entry screen and directs the person to open the app for code.
3. The person enters the verification code.
4. The system completes login, prompting for a new password if that is what triggered MFA.

• If both email and authenticator modes are enabled, a "Try another way" link is shown.

Above: Code entry screen. Help text is from MFA Settings.

Initial App Setup

Use of an authenticator app requires an initial setup register at least one device (any app will do). The code entry screen features a "manage MFA" checkbox that when checked allows the person add/remove registered devices. When there are no devices registered for the person, the box is checked by default and cannot be unchecked.

When "manage MFA" is triggered by that box being checked:

1. The system shows the "Authenticator application page".
2. The person clicks "Add new Authenticator".
3. The person opens their preferred authenticator app and choses to add a new application.
4. The person enters the code from the app into the code entry screen.
5. The person clicks Submit (device nickname optional).
6. The system validates the code and returns the person to the "Authenticator application page". 
7. The person clicks "Continue to Application" to go to ShulCloud.

Above: the "Manage MFA" screen is where people can add/remove registered devices;
"Continue to Application" takes the person to ShulCloud.

Above: Authenticator App setup screen.

Alternate MFA Workflows

There are two alternate avenues for people when things do not go a planned:

• "Try Another Way" - if a site allows more than one mode of authentication, the person can choose to use another; for example, a person who uses Authenticator could use email if the registered device is not available.
  
  
• "I need human help" - if a person has no access to any mode of authentication, the person can activate this option that will deliver a code via email to admins with the "Special: Change Password, Login as other Member" permission; 

"Try Another Way"

1. Person clicks "Try another way" link on the code entry screen.
2. Person chooses a different authentication mode.
3. Person completes authentication the other way.

Above: "Try another way" screen.

 "I need human help" 

1. The person checks the "I need human help to enter verification code (office hours only)" checkbox before submitting email address and password.
2. The system emails a verification code to admins with the password permission noted above.
3. The admin communicates the verification code to the person.

• Note that the screen still says the code was sent to the person's email. It has not. The help text is prepended with an explanation about the admins receiving the code instead. We hope to make that a cleaning experience in the future.

Above: "I need human help" checkbox shown in the Login dropdown.

Above: "I need human help" checkbox shown on a Login page.

Above: Code entry screen with "I need human help" activated.
Notice the additional help text stating that admins have received the code instead.

Additional Information

Login Links

If a person is required to complete MFA, after clicking a Login Link and providing email address and password, MFA will be required, unless the device is remembered. The Login Link provides the first authentication step but not the second, if a second is required per MFA Settings.

"Remember Me"

If in MFA settings the "remember me" option is set to a number greater than zero, after the person completes MFA, the person will be offered the option to remember the device. If the person chooses to remember the device, the person will not be asked to complete MFA again during subsequent logins during the stated period.

Above: "Remember Me" screen.

Audit Log

When a second factor is used to complete a log in, that second factor will be recorded in the audit log along with the previously recorded method (such as email/password or login link).

Above: Sample audit log entry showing use of an authenticator app to complete MFA.

Code Emails

• Emails are sent from [e-mail]; you can include an email contact in your help text in MFA Settings if desired (the same that shows on MFA screens).
  
  
• Email subject is ShulCloud Verification Code (Site Name)

"Log In as User"

Admins with sufficient permission can still log in from the People page as other people, no MFA required. Likewise, functions like account lookups on forms and the payment page are not changed by MFA.