Request approval to publish updated password guidance.

[warmanaMOJ]

Hello,

The various documents regarding password policy and guidance have been updated and reviewed, to a point where I think it is sensible to publish. Any further changes or improvements can be picked up as business-as-usual issues.

Please may I request approval to publish these documents:

• The top-level password page that explains where the detailed information is found.
• The formal policy rules that apply to passwords.
• The detailed information about the MOJ password standard.
• The general guidance about creating acceptable passwords.

Many thanks,

Adrian

[cybersquirrel]

Hello!

On the 'formal policy rules' content:

Though passwords are the primary method of User authentication, other technologies for User identification and authentication, such as biometrics and hardware tokens should be considered where appropriate.

I think there should be a statement here like:

You should carefully consider whether existing authentication systems are suitable for reuse in a new system, and avoid creating new ones. Passwords are the usual method of User authentication, but other mechanisms - which reduce the need for the user to remember something, such as biometrics, tokens, and certificate-based authentication - are to be preferred.

On the 'detailed information' content - I am unsure what the practical differences are between basic, advanced and strong passwords are. We seem to be saying that a password picked by the 'three random words' approach is basically never sufficient for access to almost any of our systems (as they're almost all multi-user)?

The MOJ password guidance uses NCSC guidance. It recommends a simpler approach to passwords. Some agencies or bodies might have specific requirements or variations. Check your team Intranet or ask your Line Manager for more information.

Suggest adding in 'some legacy systems may also not comply with modern thinking on passwords - they will have specific rules which will need to be followed' or something along those lines.

If they must be stored, do so using hash and salt values

I think this is better phrased as 'do so by using salted hashes (preferably PBKDF2)'.

A number of references in this content are quite dated - I'm not sure that IS1/2 still contain password information?

On the 'general guidance' content, I am nervous about the advice to always include a special character and a number; the NCSC guidance is much more 'pick whatever you want as long as it isn't trivially guessable' - I think we should encourage the use of any character, and for people to pick longer passwords / passphrases, but not say 'must include ...'.

It is worth noting that BitLocker PINs (which might feel a lot like a password to users) are not 8 characters, and couldn't meet these requirements (not that we would want them to).

[warmanaMOJ]

@cybersquirrel I've made substantial changes to the -standards document, and more modest ones to the -policy and -guidance files, as per your comments. The exception is regarding dated references. I certainly accept the point, but would would like to suggest that this be tackled as a separate task once the current drafts are published?

[cybersquirrel]

@warmanaMOJ thanks for this - changes look very sensible, and happy with the fixing legacy references at a later date approach. Approved!