-Passwords and Authentication Policy
--Status: DREAM -Local Boilerplate: header yes, copyright yes, defaults yes -Boilerplate: status no -TR: https://www.sr2.uk/policies/password-auth/ -Shortname: password-auth -Complain About: accidental-2119 yes -No Editor: true -!Version: 1.0 -Abstract: A policy defining an effective authentication management procedures when conducting company-related business. -- -# Objective # {#objective} - -This policy defines an effective authentication management procedures when conducting company-related business and -includes the: - -* issuing and selection of strong authentication methods and credentials; -* protection of secret authentication credentials; -* frequency of change in terms of authentication credentials; -* reporting of any suspected breach or lost authentication credentials; -* use of authentication methods with third party systems (including cloud technology). - -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. - -# Scope # {#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. - -# Definitions # {#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. - -# Policy # {#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: - -- storing authentication credentials in a secure manner; -- changing manufacturer default authentication credentials and disabling guest accounts on all equipment; -- issuing new users with temporary authentication credentials, which must be changed at first login to a stronger - alternative (defined later); -- authentication credentials issued to new users are done so in a secure manner (e.g. never in clear text via an email); -- changing all multi-user credentials (e.g. for communal equipment) used by an employee in the event that their - employment ends; -- ensuring that access to user credentials is limited to ICT administrators for the purpose of resetting, revoking or - problem resolution – authentication methods may only be reset once the identity of the user has been verified; -- locking accounts after 5 failed login attempts in order to dissuade brute-forcing attempts; -- training staff in the use of digital password managers, and the risks of storing passwords in any other form (such as - a notebook at their workstation, or Post-It note). - -Users must ensure that they do all they can to maintain the confidentiality of their authentication credentials by -never: - -- using company authentication credentials for any other account they hold (including personal accounts such as home - utilities, email, online shopping services, etc); -- having a physical copy of their credentials; -- using a non-approved method for password generation; -- entering authentication credentials on non-company equipment (for example, home or public access PCs); -- revealing authentication credentials to anyone, including line managers, unless relaying information on temporary - credentials which are changed immediately upon next login. This includes never - sharing authentication credentials with co-workers (e.g. whilst on annual leave); -- discussing authentication credentials in front of others. - -## Password Authentication ## {#passwords} - -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: - -- having a minimum number of 14 characters in length; -- using longer passwords where permitted by the service; -- including a mixture of numbers, upper and lower case letters, and special characters. - -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: - -- credential is the same, or partly the same, as the username; -- names of family members, friends, or pets are used; -- personal information about yourself or family members which can be easily found from social networking sites, - including date of birth, phone number, street name, etc.; -- consecutive alphanumeric characters or keys on the keyboard, such as ‘abc123’ or ‘qwerty’; -- dictionary words including the inclusion of a number or character at the start or end or substituting numbers or - punctuation for letters, for example, ‘P@55w0rd’; -- a known word from any language (which may not be in a dictionary). - -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: - -- end-user device login passphrase; -- password manager decryption passphrase. - -## Multi-Factor Authentication ## {#mfa} - -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. - -## Credentials for Cloud-Based Systems and Online Portals ## {#cloud} - -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: - -- not create an online account for business purposes without authorisation from a director; -- advise a director when there is no longer a need to have the online account in order to ensure that it is - removed. - -## Credential Compromise Policy ## {#compromise} - -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. - diff --git a/policies/public_wifi.bs b/policies/public_wifi.bs deleted file mode 100644 index 997c05f..0000000 --- a/policies/public_wifi.bs +++ /dev/null @@ -1,61 +0,0 @@ -
Public WiFi Policy
--Status: DREAM -Local Boilerplate: header yes, copyright yes -Boilerplate: status no -TR: https://www.sr2.uk/policies/public-wifi/ -Shortname: public-wifi -Complain About: accidental-2119 yes -No Editor: true -!Version: 1.0 -Abstract: A policy governing staff and contractor use of public WiFi networks when accessing company data. -- -# Objective # {#objective} - -The company approves remote working to work-related cloud services and work email accounts, as long as the devices used -to access these have been sanctioned by the company. Using public WiFi to conduct business, without the necessary -safeguards, places our data at risk of theft. The purpose of this policy is to provide the framework for those -safeguards. - -# Scope # {#scope} - -The scope of the policy covers all individuals either employed or contracted to work with, or for, the company, either -on a company site or remotely. - -# Definitions # {#definitions} - -: Public WiFi Network -:: Any wireless network access provided by a third party, such as hotels, cafes, airports, or public hotspots, that is - open to public or unvetted access. For the purpose of this policy, eduroam connections other than those on an SR2 - managed site are to be considered Public WiFi Networks. -: Sanctioned Device -:: A device (e.g., laptop, tablet, smartphone) that has been approved and provisioned by the - company for business use, with appropriate security configurations and software installed. - -# Policy # {#policy} - -Devices that are not sanctioned by the company, including home PCs or public access PCs, MUST NOT be used to access -company cloud services, data, or email accounts. - -Though the company takes every effort to ensure that sanctioned devices are adequately protected, the individual MUST -ensure that, before connecting to the Wi-Fi network, the device has: - -- up-to-date antivirus and antispyware software; -- a firewall that is activated and configured to company requirements (i.e. the settings have not been changed) since - the device was configured; -- all software (including the Web browser) is current with automatic updating; -- file sharing (e.g. SMB) is switched off. - -For security reasons staff and contractors MUST: - -- consider if mobile phone tethering is available and use this as the first choice; -- consider delaying transmission of information until at a secure location; -- not follow prompts to update software whilst connected to a public network; -- not rely on the encryption provided by the Public WiFi Network (e.g. WPA) to protect company data; -- ensure that an end-to-end encrypted connection is established and the user has been trained in setting up - such a connection for each service to be used (for the avoidance of doubt, TLS is considered to be end-to-end - providing that the certificate presented by the server is validated); -- ensure that URLs in Web browsers are showing the correct Web addresses in case a criminal has hijacked the Wireless - Access Point and is forwarding traffic to their site; -- keep all information secure, including restricting the view of the screen from any unauthorised person(s); diff --git a/static/.well-known/microsoft-identity-association.json b/static/.well-known/microsoft-identity-association.json deleted file mode 100644 index 4ba663e..0000000 --- a/static/.well-known/microsoft-identity-association.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "associatedApplications": [ - { - "applicationId": "1eb4853c-f999-4763-85b5-8d9bd0035bc0" - } - ] -} \ No newline at end of file diff --git a/static/cyber-essentials.pdf b/static/cyber-essentials.pdf deleted file mode 100644 index 8b27003..0000000 Binary files a/static/cyber-essentials.pdf and /dev/null differ diff --git a/static/helpdesk.asc b/static/helpdesk.asc deleted file mode 100644 index 245890c..0000000 --- a/static/helpdesk.asc +++ /dev/null @@ -1,22 +0,0 @@ ------BEGIN PGP PUBLIC KEY BLOCK----- -Comment: 1135 3E54 83C7 152B 165C 46A7 9CE7 365E C2E1 4728 -Comment: SR2 Helpdesk (Shared Mailbox)
TLP:CLEAR
- -
-
- 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 -
© SR2 Communications Limited.
-This document is licensed under CC BY 4.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:
--
-
-
-
issuing and selection of strong authentication methods and credentials;
- -
-
protection of secret authentication credentials;
- -
-
frequency of change in terms of authentication credentials;
- -
-
reporting of any suspected breach or lost authentication credentials;
- -
-
use of authentication methods with third party systems (including cloud technology).
-
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:
--
-
-
-
storing authentication credentials in a secure manner;
- -
-
changing manufacturer default authentication credentials and disabling guest accounts on all equipment;
- -
-
issuing new users with temporary authentication credentials, which must be changed at first login to a stronger -alternative (defined later);
- -
-
authentication credentials issued to new users are done so in a secure manner (e.g. never in clear text via an email);
- -
-
changing all multi-user credentials (e.g. for communal equipment) used by an employee in the event that their -employment ends;
- -
-
ensuring that access to user credentials is limited to ICT administrators for the purpose of resetting, revoking or -problem resolution – authentication methods may only be reset once the identity of the user has been verified;
- -
-
locking accounts after 5 failed login attempts in order to dissuade brute-forcing attempts;
- -
-
training staff in the use of digital password managers, and the risks of storing passwords in any other form (such as -a notebook at their workstation, or Post-It note).
-
Users must ensure that they do all they can to maintain the confidentiality of their authentication credentials by -never:
--
-
-
-
using company authentication credentials for any other account they hold (including personal accounts such as home -utilities, email, online shopping services, etc);
- -
-
having a physical copy of their credentials;
- -
-
using a non-approved method for password generation;
- -
-
entering authentication credentials on non-company equipment (for example, home or public access PCs);
- -
-
revealing authentication credentials to anyone, including line managers, unless relaying information on temporary -credentials which are changed immediately upon next login. This includes never -sharing authentication credentials with co-workers (e.g. whilst on annual leave);
- -
-
discussing authentication credentials in front of others.
-
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:
--
-
-
-
having a minimum number of 14 characters in length;
- -
-
using longer passwords where permitted by the service;
- -
-
including a mixture of numbers, upper and lower case letters, and special characters.
-
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:
--
-
-
-
credential is the same, or partly the same, as the username;
- -
-
names of family members, friends, or pets are used;
- -
-
personal information about yourself or family members which can be easily found from social networking sites, -including date of birth, phone number, street name, etc.;
- -
-
consecutive alphanumeric characters or keys on the keyboard, such as ‘abc123’ or ‘qwerty’;
- -
-
dictionary words including the inclusion of a number or character at the start or end or substituting numbers or -punctuation for letters, for example, ‘P@55w0rd’;
- -
-
a known word from any language (which may not be in a dictionary).
-
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:
--
-
-
-
end-user device login passphrase;
- -
-
password manager decryption passphrase.
-
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:
--
-
-
-
not create an online account for business purposes without authorisation from a director;
- -
-
advise a director when there is no longer a need to have the online account in order to ensure that it is -removed.
-
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:
-
-
- 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 -
TLP:CLEAR
- -
-
- Public WiFi Policy
-Draft for Approval by Company Directors, - 22 April 2026 -
--
-
- Latest published version: -
- https://www.sr2.uk/policy/public-wifi/ -
- Version: -
- 1.0 -
© SR2 Communications Limited.
-This document is licensed under CC BY 4.0.
-
-
Abstract
-A policy governing staff and contractor use of public WiFi networks when accessing company data.
-1. Objective
-The company approves remote working to work-related cloud services and work email accounts, as long as the devices used -to access these have been sanctioned by the company. Using public WiFi to conduct business, without the necessary -safeguards, places our data at risk of theft. The purpose of this policy is to provide the framework for those -safeguards.
-2. Scope
-The scope of the policy covers all individuals either employed or contracted to work with, or for, the company, either -on a company site or remotely.
-3. Definitions
--
-
- Public WiFi Network -
-
-
Any wireless network access provided by a third party, such as hotels, cafes, airports, or public hotspots, that is - open to public or unvetted access. For the purpose of this policy, eduroam connections other than those on an SR2 - managed site are to be considered Public WiFi Networks.
- - Sanctioned Device -
-
-
A device (e.g., laptop, tablet, smartphone) that has been approved and provisioned by the - company for business use, with appropriate security configurations and software installed.
-
4. Policy
-Devices that are not sanctioned by the company, including home PCs or public access PCs, MUST NOT be used to access -company cloud services, data, or email accounts.
-Though the company takes every effort to ensure that sanctioned devices are adequately protected, the individual MUST -ensure that, before connecting to the Wi-Fi network, the device has:
--
-
-
-
up-to-date antivirus and antispyware software;
- -
-
a firewall that is activated and configured to company requirements (i.e. the settings have not been changed) since -the device was configured;
- -
-
all software (including the Web browser) is current with automatic updating;
- -
-
file sharing (e.g. SMB) is switched off.
-
For security reasons staff and contractors MUST:
--
-
-
-
consider if mobile phone tethering is available and use this as the first choice;
- -
-
consider delaying transmission of information until at a secure location;
- -
-
not follow prompts to update software whilst connected to a public network;
- -
-
not rely on the encryption provided by the Public WiFi Network (e.g. WPA) to protect company data;
- -
-
ensure that an end-to-end encrypted connection is established and the user has been trained in setting up -such a connection for each service to be used (for the avoidance of doubt, TLS is considered to be end-to-end -providing that the certificate presented by the server is validated);
- -
-
ensure that URLs in Web browsers are showing the correct Web addresses in case a criminal has hijacked the Wireless -Access Point and is forwarding traffic to their site;
- -
-
keep all information secure, including restricting the view of the screen from any unauthorised person(s);
-
- 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:
-
-
- 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
--
-
- [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 -