About usernames, passwords and expiry dates
If you create accounts manually, you need to know about the makeup of usernames and passwords so you don't get slowed down by having them rejected by the system.
About usernames
Usernames must be unique and are not case sensitive when you or your account holders enter them. They are always displayed in lower case.
They must be at least 6 characters long and can be as long as 20 characters. All usernames will start with a prefix unique to your organisation. If you use any form of automated account creation, such as self-registration or bulk upload, usernames will be in a predictable format.
If you are allowing email addresses to be used as usernames, then the email addresses will also need to be unique.
About passwords
Password length must be between 10 and 100 characters and pass a strength assessment.
Passwords are case sensitive, and just about any character from any language is fine - if it's on the keyboard you're using it should be ok.
Passwords cannot:
- be the same as the username,
- contain words known by hackers to be commonly used such as 'password' or 'letmein' (not a complete list)
- contain non-printable characters such as control codes
Examples:
This one is too short and is a common word - the confirm button is dimmed and will not work
This is long enough, but still common words
This one is much longer, so common words aren't as important. These examples are taken from the XKCD cartoon (https://xkcd.com/936/), so don't use that one.
This final example might pass some password policies, but it's essentially the same as "mypassword" to a cracker:
(The pictures are from the end-user facing version)
For the best security, your own passwords should be difficult to guess but easy for you to remember. Length is better than complexity and since spaces are allowed, a passphrase is an easy way to get something long, secure and unique. Here are some more examples of passwords that would be accepted if used (don't use these ones though):
सही घोड़ा पियानोправильный конь пианиноריכטיק פערד פּיאַנעσωστό πιάνο αλόγωνkārtīgas zirgu klavieres
The best policy is for users to always set their own passwords, but this is not always possible. In those cases you should avoid (so far as is practical):
- using the same password each time
- basing them on personal information such as
- names
- emails
- birthdays
- published or predictable patterns
- replacing letters in easily guessable words with numbers - e.g. "p455word" is no better than "password"
The safest way to reset user passwords is to trigger an activation email and let the account holder do it themselves.
Further reading: https://www.ncsc.gov.uk/collection/top-tips-for-staying-secure-online/three-random-words
About expiry dates
The account becomes expired ON the expiry date - i.e. it does not allow the user to log in on the expiry date. The same is true of any other types of expiry date that may be in use by your organisation's schema such as eligibility expiry or permission set expiry. Dates and times are UTC rather than where the home organisation is, or where the user might appear to be.
Expiry reminder emails, if enabled, are sent 30 and 15 days before expiry.