Notes first published June 24, 2020
Update available from June 24, 2020
Version 6.5 of Smartabase contains exciting new functionality, which will be available to you shortly. The main themes for this update are security-related configuration options and user interface improvements. Here's a short overview of what’s new:
- More configuration options for password criteria.
- Password policies that can be applied to specific types of people (using roles).
- Explicit control for how multi-factor authentication (MFA) codes are communicated (SMS, email and/or authenticator application).
- Collapsible sidebars across the Smartabase web application to provide more screen space.
- A new tool for whitelisting IP addresses to reduce unnecessary multi-factor authentication (MFA).
- Expanded configuration options for connections between enterprise sites.
More configuration options for password criteria
In version 6.2 of Smartabase we added the ability for you to request changes to the site-wide password policy. Now, in version 6.5, we’ve added more options to help you increase the security of your organization's people and data. This means that, as a default for your Smartabase site, we can help you to specify:
- Maximum password change frequency - how often can someone’s password be changed?
- Enforced password changes after a set period - how long should a password be useable for?
- Prohibiting the use of previous passwords - should people be able to re-use old passwords?
- Prohibiting matches to common patterns - is it okay for passwords to include sequences like 1234 or qwerty?
- Maximum password length - can people make passwords longer than, for example, 24, 35 or 90 characters?
Please reach out to your service team contact if you want to make changes to your default password policy. Also note that these new criteria are also available for role-specific password policies (see below for more on this).
(!) Warning: to maintain our commitment to the security of your data, Smartabase is required to make certain changes to all current default password policies. These changes will come into effect on all sites as they are updated to version 6.5 of Smartabase:
- Maximum password change frequency will be set at two (2) per day by the user account owner and five (5) per day per user account when carried out by a site administrator.
- Preventing re-use of previous passwords: the eight (8) most recently used passwords will not be accepted for use as a new password.
Because this is a change to the default policy, all accounts are covered by these protections, including athletes, coaches, team administrators, site administrators, site builders and accounts used for integrated technologies, Smartabase support or internal testing within your organization.
Create password policies for roles
You can now make use of a new password policy management tool for administrators to configure and apply password policies on a role-by-role basis. If someone has multiple password policies (for example, because they have two roles), the strictest criteria from each policy will be enforced. Note that this measure also takes into account the site-wide policy, so if a policy created by an administrator is less strict than the site policy, the site policy will override the administrator’s policy.
Because password policies have an immediate and significant effect on the login experience for people accessing Smartabase, we’ve added a special system permission for using this tool. Please contact our customer service team if you would like to use the password policies tool within your organization, and we’ll make sure you’ve got everything you need to know to use it effectively.
Choose how multi-factor authentication codes are communicated
Many of you are using multi-factor authentication (MFA) to help the members of your organization keep their account secure. In previous versions of Smartabase, when someone went through the process of multi-factor authentication, Smartabase would generate and send a time-based-one-time-password (MFA code) via email and SMS (text message). People could also generate the MFA code using an authenticator app, but they’d always receive the MFA code as a communication from Smartabase as well.
In Smartabase version 6.5, there are three specific preferences for the method of getting an MFA code:
- Authentication app only (most secure).
- SMS or authentication app.
- Email, SMS or authentication app (least secure).
Like password policies, there is more than one level at which MFA communication preferences can be set:
- As site-wide default setting - your Smartabase consultant can put this in place for you.
- On a role-by-role basis, set by a Smartabase administrator.
- At the individual user account level, chosen by the user account owner.
Note that, as with password policies, a strict setting at the site or role level will reduce the choices at the role or user account level respectively. So if you update someone’s role to only communicate MFA codes via authentication app or SMS, they won’t see the option in their user account to receive MFA codes via email.
Collapse sidebars across the Smartabase web application
Every time you see a sidebar in the Smartabase web application, you can now collapse it! This gives everyone more space to view and interact with their data.
This applies to all areas of the user interface, including within the administration and building interfaces. For example, you can collapse the sidebar menu that houses controls for the resources tool to have more screen space to review your search results. Then, hover your mouse over the collapsed sidebar border to bring back the resource search menu and interact with the controls in it.
Whitelist trusted IP addresses to avoid unneeded multi-factor authentication
If you’re a Smartabase administrator, you may be able to make use of the new security whitelisting tool (talk to your Smartabase consultant for training and access first). We built the whitelisting tool for organizations with multi-factor authentication set up for people using trusted and known IP addresses. With the whitelisting tool, you can specify a list of IP addresses that are trusted.
Anyone logging into Smartabase from a whitelisted IP address won’t be required to re-authenticate whenever a network change is detected.
Expanded configuration options for connections between enterprise sites
We are continually working on improving support for our enterprise customers, and as a result we’ve significantly expanded the flexibility of how the information can be linked between sites in hierarchical and peer-to-peer server configurations. Moreover, these linking options are now quicker and easier to use so that we can support our customers more efficiently. Please reach out to our service team if you are considering using an enterprise server configuration in your organization or would like to know more.
General improvements and bug fixes
- It’s no longer possible to include commas in the email address field for a user account.
- New Zealand daylight savings rules were being applied to the date of birth field in user accounts, which caused the date to be wrong in rare cases. This is now fixed.
- We’ve addressed multiple issues with the process of managing performance alerts.
- Some enterprise customers experienced issues with unlinked or deleted user accounts not being removed from child sites - this has now been fixed.
Highlights from your last Smartabase release notes
In the last release notes, for Smartabase 6.4, we announced:
- The ability to resave event form data for selected periods.
- A new advanced form property to disable event conflict notifications for specific event forms.
- Improvements to how Smartabase handles signatures and calculations for recording the date of entry when these are part of a table in an event form.
If you missed them, you can read the last Smartabase release notes here.