Password Policy

SOC 2 Criteria: CC6.1
ISO 27001 Annex A: A.9.2.4, A.9.3.1

Keywords: Password requirements, Password Manager, Complex passwords, 2FA, MFA

Purpose

This policy describes the procedure to select and securely manage passwords at Bramble.

Scope

This policy applies to all Bramble employees, contractors, and any other personnel who have an account on any system that resides at any company facility or has access to the company network.

Roles and Responsibilities

Bramble’s Security Officer is responsible for updating, reviewing, and maintaining this policy.

Policy

If a password is suspected of being compromised, the password in question should be rotated and the Security Officer should be notified immediately.

Bramble Password Policy Guidelines

Passwords are one of the primary mechanisms that protect Bramble information systems and other resources from unauthorized use. Constructing secure passwords and ensuring proper password management is essential. Bramble’s password guidelines are based, in part, on the recommendations by NIST 800-63B. To learn what makes a password truly secure, read this article or watch this conference presentation on password strength.

Bramble team-members Password Requirements

At Bramble, we enforce a strong password requirement, which consists of minimum length of 12 characters.
To make a secure password you can remember, consider using a combination of 5 or more random words
The use of special characters is not required or even recommended.
Avoid creating predictable passwords.
Passwords cannot be reused.
Passwords should not be the same as username.
Passwords should be unique from the previous passwords used.

Password Management

Password “hints” are not to be used. If a password is forgotten, a mechanism must be in place to replace a password/passphrase with sufficient controls to verify the identity of the requester of the password reset.
Passwords must be stored in a way that is resistant to offline attacks and must be salted and hashed using a suitable one-way key derivation function.
If a password is required to be stored, it must be stored within an approved password manager application and may be pasted from this using a master password function (e.g. KeePassXC).
Passwords are to be kept private and secured.
If an account or password is suspected to have been compromised, report the incident to Security and promptly follow their instructions.
Passwords are not to be shared or be in clear text or be written down.

System Password Requirements

For systems where a password can be configured the minimum password length needs to be set to 12 characters.
To make a secure password you can remember, consider using a combination of 5 or more random words
The use of special characters is not required or even recommended.
If a particular system will not support 12 character passwords, then the maximum number of characters allowed by that system shall be used.
If a particular system requires a password history, configuration should be set for 25 remembered passwords.
Passwords are not acceptable if they match the subsequent patterns, and must be checked against commonly used or expected patterns, including known breached password lists, dictionary words, repetitive or sequential characters, or context specific words, such as the name of the service, username, or derivatives thereof.
System administrators of applications and or devices must change default passwords.
System administrators need to enable password strength on third party applications and or tools, where applicable.
For applications where a password is the only source of authentication a password must be expired within a maximum of 90 calendar days.
Systems should monitor and log failed login attempts.
Authentication failed login attempts information needs to be recorded within the application logs such as: name, date, number of failed attempts, unique log identifier.
Repeated failed login attempts must trigger a temporary account lockout after 10 failed attempts. The lockout may end after a designated period of time, or require a manual unlock, depending on the profile of the application.

Two Factor Authentication

All Bramble team members should use Two Factor Authentication (2FA) whenever possible. Usage of 2FA by Bramble team members is required for access to the production environment. It should be noted that references to MFA (Multi-Factor Authentication) are often included in language associated with third party products and certain Compliance references (e.g. IAM.2.03 - Multi-factor Authentication ), but the general concept is still covered by the term “2FA”. There are different 2FA methods that can be used by Bramble team members. These are ranked by security strength:

U2F. U2F (Universal 2nd Factor) uses a hardware token and is considered the most secure method, assuming the hardware token itself is physically secured.

TOTP. TOTP (Time-based One Time Password) is a popular method for a second factor. This can be done via a mobile app (Google Authenticator, Duo Security, etc) although there are some software implementations as well. While not as secure as U2F or Push as TOTP could be phished (although the attack window would be extremely short), it is still a very secure method of authentication. As KeePassXC is used by Bramble team members, this could be used for TOTP after proper configuration (see below).
SMS. SMS (Short Message Service) is a method of using text messaging to provide out-of-band (OOB) authentication. As the messages can be spoofed or intercepted more easily than other methods, SMS is not recommended for 2FA. As of this writing the Security Department is unaware of Bramble assets or third party applications that team members are using that only support SMS 2FA, but if you need to use something that only offers SMS as a second factor for Bramble, contact the Security Department.

There is a reason that multiple 2FA methods are supported (e.g. Okta supports U2F, Push, and TOTP). Situations are different for different team members. For team members that travel a lot, they might feel more comfortable using Push instead of U2F if they are concerned about losing the hardware token during their travels. Many team members us KeePassXC and TOTP for the convenience. Many services support configuring multiple methods, which can be used for different situations or as a backup if a factor is lost. The idea is that we give team members a choice so that they can adapt a 2FA solution that best suits their needs. Again, contact the Security Department if you have questions.

For a better understanding of how 2FA fits into Bramble, refer to the Accounts and Passwords section, which includes pointers to setting up passwords, acquiring U2F tokens, and links to further resources.

Application Authentication Requirements

Authentication to an application should contain Multi-Factor authentication (Token, OTP Generator, SSO, YubiKey/Titan or equivalent) and or a SAML Assertion after logging into an authentication portal is recommended (e.g., Okta).
Authentication to an application should support individual users, not groups.
Acceptable secondary authentication factors include Authy, Google Authenticator or similar software implementing a One-time Password algorithm. The use of biometrics is acceptable.

Exceptions to Password Policy

Any application that can not meet MFA and or Password requirements needs to submit an exception for the Compliance team to review. A duration of an exception is valid for 90 days followed by a proper remediation plan. After 90 days the exception will be reevaluated.

KeePassXC Guide

KeePassXC is a password manager. Ideally you memorize one strong password - hence the name - and let KeePassXC generate and manage strong, unique passwords for every site for which you have a login.

Enforcement

An employee or contractor found to have violated this policy may be subject to disciplinary action.