Consistent and meaningful usernames on systems become more important as an organisation grows. Without control the number of disused accounts on systems will grow until it takes a major project to resolve the issue. One of the worst cases we have seen was an organisation which had tens of thousands of unexplained user accounts.
Failure to control the usernames and user accounts reduces individual accountability for actions and makes security investigations difficult. It makes the systems more accessible for those with malicious intent. It also makes it impossible to be sure that an individual can be locked out of the systems should it be necessary to do so.
Because the number of systems in an organisation can grow quickly and as it’s a difficult problem to resolve once bad practice has taken off, it’s important to have a well communicated naming convention policy as early as possible.
The policy doesn’t need to be, and shouldn’t be, overly complex. It must address key issues: usernames must be unique and must support auditing and security analysis. It’s essential for the username policy to be documented as early as possible - variations in the interpretation of the policy will arise if it remains folklore. Here are some suggestions for key statements in the username policy that you could consider or adjust to fit your requirements.
How to choose a username
Usernames related to the user’s actual name make reviewing audit logs simpler as well as making life easier for the users. This may sound obvious but occasionally you find an organisation using personnel numbers or other identifiers.
Maximum username length should also be considered - many systems permit long usernames these days but restricting the length to eight characters (or the smallest limit of your existing systems) will ensure maximum compatibility. It will also make life easy for those with long names and no touch typing skills. Ensuring that only numbers and letters are in usernames may improve compatibility too - having ‘o’hara’ as a username will break something somewhere!
You may also find a small security improvement if you avoid using just common names (e.g. jim) as complete usernames. One common type of attack involves attempting an easy password (e.g. 123456) with a whole series of common usernames, hoping that one user will have chosen it. You’ll see this attack in your logs after a while if you leave a router or server unsecured and connected to the Internet for a week or two.
How to ensure consistency
The policy should mandate the use of a central list of usernames, tying users to individuals. It may seem that having a policy of first name followed by surname will cover all eventualities, but once the third John Smith joins the company it’ll rapidly become unclear which johnsmith2 is which. Making the username a field in the internal phone or email directory works well.
Slightly counter-intuitively, specifying the format precisely (e.g. two characters of the user’s first name followed by six of the surname) will lead to assumptions about the correct usernames of individuals. Administrators will then stop using a central list to ensure consistency and where subtle changes arise, the two John Smiths for example, mistakes will be made.
Reuse of names
Consider banning the reuse of names even after someone has left. Allowing usernames to be reused can open up previous users’ files and applications to new users. It will also frustrate attempts to understand audit logs.
If you must reuse names then use a minimum period between reuse and ensure that all systems are properly cleaned of all traces of the previous accounts. However, we would recommend that when an employee leaves your organisation the username should be marked as ‘left’ in the directory and not removed. This ensures there is no future duplication.
If you use UNIX systems it may be worth pointing out that the numeric UID associated with each user should never be reused.
Third-party access
Where customers or suppliers have access to systems - especially where they share accounts with internal staff - managing the usernames carefully becomes very important. In order to delineate between internal and external user accounts, we recommend that a customer or supplier’s username is prefixed with a zero or similar, immediately recognisable, symbol.
Shared accounts
Shared accounts are to be avoided, both deliberately shared (an account for support staff, for example) and secretly shared (use my account then you can access that application).
The trick here is to have enough control over the creation of accounts that unauthorised accounts don’t appear on systems, while making account creation easy and quick enough so that users don’t feel that it’s just too difficult to get an account of their own.
Where possible, implement controls to identify an account being used from more than one machine at once and then have a quiet word with whoever is sharing the account.
In summary
Having a set of simple rules like these makes the management of security far easier. For example, it reduces the risk of deleting the wrong account when someone leaves, or identifying who changed a particular file. It will also make life straightforward for your users.
Make sure the rules are communicated to all the staff who need to know them - probably those with administrative access (but include contractors, even those just in for a couple of days). Getting your systems compliant with a user naming policy may seem like a mundane task but it is essential as your business grows.
Account Management Best Practice
- Usernames must be eight characters or less and must only contain letters and/or numbers. The username should ideally be representative of the user’s first name and surname.
- When creating an account on a system the username for the user must be taken from the master username list.
- Usernames must not be reused. We recommend that ex-employee’s usernames should be marked as ‘left’ in the directory and not removed.
- When giving a customer or supplier username access to your systems, prefix the username with a zero or similar, immediately recognisable, symbol.
- Shared accounts must not be used.
- New systems should be designed, where possible, to create an alert when an account is being used simultaneously from more than one location.