Web App Password Policies
Password policies have evolved a lot over the years, so this document is to outline the policy we try to use at Agile Collective when applying to client web applications.
Note that our internal password policy can be found on our password handbook page.
Tldr
DO
- DO put in a minimum length (eg. 12+)
- DO put in some help information about "three random words" or similar
- DO restrict commonly used passwords in Drupal using the
password_policy_blacklistsubmodule password_policy and copy/paste from a known password blacklist - DO prevent passwords being the same as the username
DON'T
- DON'T put requirements on characters (eg. case or special characters)
- DON'T force password resets, unless compromised
- DON'T put in a maximum length
OPTIONAL
- (client option) TFA
- (client option) auto logout after x hours
Background
- NIST (National Institute for Standards and Technology) and NCSC (National Cyber Security Centre) have both moved away from "complexity requirements" in passwords.
- GDS (Gov.uk Design System) also follow similar rules
- CyberEssentials also appears to focus on length and blacklisting rather than complexity rules
- "three random words" seems to be the recommended approach
- We should include a few safety nets though, such as:
- Minimum character lengths of 12+ (strong CyberSecurity)
- Checking a known blacklist of common/unsafe passwords (strong CyberSecurity)
- It is also recommended to not force users to reset their passwords unless there has been a data breach of some form
- With regards special characters, the reasoning for this is around memorability, and that not everyone has access to a password manager. If this can be guaranteed (eg. for our internal passwords via passbolt) then we can continue to do this.
Why the change?
NCSC
Using complexity requirements ... is a poor defence against guessing attacks. It places an extra burden on users, many of whom will use predictable patterns (such as replacing the letter ‘o’ with a zero) to meet the required 'complexity' criteria. Attackers are familiar with these strategies and use this knowledge to optimise their attacks. Additionally, complexity requirements provide no defence against common attack types such as social engineering or insecure storage of passwords.
GDS
Do not make users keep changing their passwords
Some services force users to change their passwords regularly, for example every month.
You should not do this because it means users:
- are more likely to forget their passwords
- will tend to pick simple variations on their previous password
- are more likely to store their password in a non-secure place
Usually, you should only force a password change if you suspect an account might be compromised.
Cyber Essentials
(via blog post about CyberEssentials)
What’s NOT required (despite popular belief)
- Forced password rotations — explicitly discouraged in the current spec. Don’t force 90-day changes. Rotate only when there’s evidence of compromise.
- Specific complexity rules — e.g. “1 uppercase, 1 number, 1 special character” — not required. Length is what matters.
- Password history of 24 — not required.
- Custom security questions — not required and generally insecure.
- Hardware tokens for MFA — accepted but not required. Authenticator app, SMS codes (least preferred), push notification, biometric, hardware key — all accepted.
This was a genuine 2022-2023 update from the older NCSC password guidance. If you’re working from older internal documents, time to revise them.
Last updated: