Password Policy Management

Data protection and security are critical aspects of collecting and storing data for your users. As the first line of defense, password requirements should reflect the security needs of your organization, as well as any legal requirements in place in your geographic location.

Each Smartabase site is set up with a site-wide (or default) password policy. This policy sits in the Application details tool on the builder interface, and can only be edited by the site owner. 

In addition to the site-wide password policy, it is also possible to create role-specific policies via the administration interface, if this has been enabled in the site's Application details. Any administrator or team administrator with the appropriate system permission can access this tool.

When setting up a password policy, you have several options to adjust how strict your password requirements will be, based on the following settings:

• Minimum password length: this will determine the minimum number of characters required for a password. At Smartabase, we recommend a minimum of 10 characters or higher as best practice.
• Maximum password length: this will determine the maximum number of characters required for a password.
• Minimum lowercase, uppercase, numeric and special characters: each of these values will determine the minimum number of characters of their respective types.
• Allow PIN login: this allows you to enable or disable logging into the Smartabase app using a PIN. The setting does not currently apply to the Smartabase Athlete or Kiosk apps.
• Passwords expire: enabling this setting will enforce periodic password resets by all users assigned to the policy. The reset frequency is determined by the Password lifetime (days) setting.
• Prevent previous password: if enabled, this setting will prevent someone from re-using the last X number of passwords, based on the Previous to ban setting.
• Ban common patterns: this setting prevents the user from creating a password with commonly used patterns, such as repetitions or sequences of numbers, characters or symbols. Enabling this setting will prevent patterns such as 1234, 111, BBB and !@#$ from being included in a password.
• Ban custom patterns: if you would like to prevent people from using specific patterns (not just generally recognized common patterns), you can use this setting to upload at .txt file containing these additional banned patterns. For example, you can prevent people from using your organization's name or their team name in their password. Once this file has been added to your password policy, people won’t be able to use any of the included patterns in their passwords. Each pattern must be entered into a separate row within the file, and the values entered are not case-sensitive.
• Banned password: similar to banning custom patterns, you can also ban specific combinations from being used as an entire password. These are also uploaded via a .txt file (with one entry per row), which will prohibit people from using any of the included passwords. Unlike banned custom patterns, these entries are case-sensitive so passwords with alternative capitalization or characters will not be banned. For example, if you add Pineapple!! as a banned password, someone would still be permitted to use Pineapple!!1, pineapple!! or Pineapple! when setting up their password.
• Number of changes allowed by a user in 24 hours: this setting enforces the number of times a password can be changed by a user within a 24 hour period since the last change. This setting is locked at 2, and cannot be adjusted.
• Number of changes allowed by an administrator in 24 hours: this setting enforces number of times a password can be changed by an administrator within a 24 hour period since the last change. This setting is locked at 5, and cannot be adjusted.

When both the default policy and a role-specific policy have been set up, it is likely they'll have some inconsistencies. For any conflicts, the strictest setting will be used. For example, if the Minimum password length in the default policy is set to eight characters but a person's role policy is set to 10 characters, the password will require 10 characters. Similarly, if the default policy has Ban common patterns enabled but the role policy does not, the default policy's stricter setting will be enforced.

Best-practice password policy recommendations

Encouraging the use of passphrases within your organization can be an effective way of increasing account security. Passphrases are sequences of words, like a process you do every day (SleepWakeShowerBrushWork) or a list of items (LampCouchLightSpeaker). They tend to be longer than typical passwords but easier for people to remember. If you want to create a password policy that supports the use of passphrases, you could increase the minimum password length and reduce the requirement for numeric characters.

If you’re changing a password policy on your site, it’s important to consider the implications this will have on the site’s security. For example, a stricter password policy will be more secure, but may frustrate people who have to adhere to the strict settings. Alternatively, a lenient policy can make it easier for people to create and remember a password, but their password could be more easily guessed by an attacker. Different geographic locations and types of organizations may also have specific compliancy requirements, so make sure you’re aware of any that may apply to you when setting up a password policy.

The list below outlines our recommended best-practice minimum requirements for secure password policies, with reference to default settings (recommended minimum for regular people like athletes, coaches and sport scientists), sensitive settings (recommended minimum for people with access to sensitive data, such as medico-legal information) and military settings.

^Explicitly defined as minimum level of security required for National Security Systems (NSS) by CNSSI 1253 for Moderate/Moderate Baseline - considered a reasonable baseline for GovCloud default configuration.

*Not explicitly defined by compliance requirement but recommended by Smartabase as appropriate options for NSS. These can be negotiated if they’re too complicated or restrictive for people connecting to your site.