TLP:CLEAR

SR2 Communications Limited

Passwords and Authentication Policy

Draft for Approval by Company Directors, 22 April 2026

Latest published version:
https://www.sr2.uk/policy/password-auth/
Version:
1.0

Abstract

A policy defining an effective authentication management procedures when conducting company-related business.

1. Objective

This policy defines an effective authentication management procedures when conducting company-related business and includes the:

Authentication is a key method of securing our information – choosing weak authentication methods, or failing to keep the authentication credentials secure, places the confidentiality of our data at risk.

2. Scope

The scope of the policy covers all individuals either employed or contracted to work with or for the company, either in-office or remotely.

3. Definitions

Authentication method

Any method by which a user may authenticate themselves in order to gain access to a location, data or service, such as text entry (e.g. passwords, passphrases, PINs), biometrics (e.g. fingerprints), etc.

Authentication credentials

The specific data or information used by a user to authenticate themselves, including but not limited to passwords, passphrases, PINs, and biometric data.

Multi-Factor Authentication (MFA)

An authentication method that requires the user to provide two or more verification factors to gain access, such as something they know (e.g., password), something they have (e.g., a security token or mobile device), and/or something they are (e.g., biometric data).

Cloud-based system

A service or platform hosted over the internet that allows users to access data, applications and services remotely.

Password manager

A software product used for the secure storage of passwords, which must be approved for use, and includes functions for generating strong passwords compliant with this policy.

4. Policy

Authentication method covers any methods by which a user may authenticate themselves in order to gain access to a location, data or service, such as text entry (e.g. passwords, passphrases, PINs), biometrics (e.g. fingerprints), etc. The company ensures that authentication credentials are kept confidential by:

Users must ensure that they do all they can to maintain the confidentiality of their authentication credentials by never:

4.1. Password Authentication

Many services and policies only allow for password authentication methods, and so they are given a special focus here. Strong passwords MUST be used for authentication. The company defines a strong password as one generated by one of two processes: random string generation by a password manager or using diceware [EFF-DICE].

Where a password is to be stored in a password manager, it MUST be randomly generated by the password manager with the parameters:

Where special characters are not possible due to technical restrictions, the minimum length is 20 characters.

For the avoidance of doubt, weak passwords must never be used. Weak, text-based authentication credentials generally have one or more of the following characteristics:

For passwords that are intended to be memorised, the MUST be generated using diceware. The above restrictions likely will not be met using this method as the intention is to provide a strong password that is easy to remember, and the strength comes from the underlying dice rolls. Any other method of generating a passphrase MUST NOT be used even if it results in one that bears similarity to a diceware-generated passphrase.

Memorised passphrases generated with diceware SHOULD be used for:

4.2. Multi-Factor Authentication

Wherever the option is offered by a given service or piece of software, multi-factor authentication is to be used (e.g. a fingerprint and a passphrase, or a voice sample, PIN and verification SMS).

Where a hardware token is in use to authenticate to a system without a password, the token itself MUST be secured with a memorised PIN of at least 6 digits.

4.3. Credentials for Cloud-Based Systems and Online Portals

It is to be remembered that the company makes use of cloud-based technology and online portals, which may not enforce strong authentication credentials. It is therefore up to the individual to ensure a good authentication regime is maintained, which is as strong as that used within the organisation. In line with the company’s "Internet Use Policy", users shall:

4.4. Credential Compromise Policy

In the event of a credential compromise, users SHALL take immediate action to secure the account by resetting or invalidating the credentials and report the incident to a director as soon as practical. It is policy that any password compromise event will be shared with CiviCERT members via the MISP platform to allow for shared learning from the incident. Directors will be responsible for determining if a data breach notification is necessary to our clients or to the Information Commissioners Office.

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

References

Normative References

[EFF-DICE]
EFF Dice-Generated Passphrases. URL: https://www.eff.org/dice
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119