User Accounts and Password Policy

1.0 Objectives

Generally, access to the Information Technology (IT) facilities of the University of Moratuwa (UoM) requires users to prove their identity to the respective system(s). This is usually achieved by the use of a username and password combination. This document provides a unified policy on how user accounts are to be created and requirements on the complexity, transfer, use, and storage of passwords and other authentication credentials. This policy to be applied uniformly across all of the University IT facilities and to be interpreted along with the UoM’s IT Policy and Information Security Policy.

2.0   User Accounts

2.1 Types of Accounts

A User is anyone who accesses UoM IT facilities, whether affiliated with the University or not, whether on campus or from remote locations, including but not limited to students, faculty, staff, consultants, temporary employees, guests, volunteers, and contractors. More specifically:

1. Internal students with a currently valid registration, either full-time or part-time
2. Staff in current employment with the UoM, either permanent or contract
3. Personnel of the UoM departments, divisions, projects, etc., with a valid authorization for the use of IT facilities given by the Head of the relevant unit
4. External users with a currently valid authorization for IT facilities use either by the Head of the relevant unit or Center for IT Services (CITeS)

 

Access to the UoM IT facilities is provided through a computer account identified by a username. Thus, User Account is a unique reference assigned to a user to enable a computer system to identify that individual uniquely. User accounts are further classified whether it is given for a faculty member, member of administrative staff, student, visitor, to reflect a specific role, task, or event, or for a project. An account not used by a user, but by one computer system connecting to another computer system, is referred to as a  System Account. Username assigned to both user and system accounts should be unique where precisely one user or service must be mapped to an account.

 

2.2 User Account Creation

All authentication should take place using the University’s central authentication services. When system-level constraints prevent the use of central authentication and/or full implementation of this Policy, CITeS needs to be informed of the limitation, and possible cause of actions should be discussed and agreed with the Director, CITeS before commissioning of those services or hardware equipment for production use.

A user account should be created by CITeS or other systems Administration only when a written or e-mail request is received from the respective head of the department (in case of e-mail requests, the official e-mail address should be used). User accounts for students should be created only via a request from the Examination and Registration Division. A typical request to create an account should include the following details:

1. Full name of the user, role, task, or project
2. NIC No, Student ID, employee ID, or other forms of ID as applicable for the type of account created
3. Contact details, e.g., phone no and alternative e-mail address
4. Type of account
5. User’s full-time/part-time status
6. Account active duration (for visitor, event, or project accounts only)
7. Name of department or division
8. 2 to 3 preferred usernames as per the guidelines in Section 2.3

 

A user will be given access to a particular information system, hardware, or network only if such operation is a part of, or directly related to the teaching, learning, research, or administrative workload of the academic or administrative unit.

 

2.3 Format of a Username

Depending on the user’s role a username should be an alphanumeric string in the format specified in Table 2.1. In all possible cases, every attempt must be taken to issue a unique username that works across all University services such as e-mail, LMS, and MIS. Usernames are given on a first come first serve basis. Alias is given only under specific circumstances, and a detailed justification for the use of the alias needs to be given.

The request must be approved by the Director, CITeS before to creating the alias. In case of an alias primary username should still be in line with the Table 2.1.

 

Table 2.1 - Recommended format of a username.

Account Type	Constraint	Format	Example
Faculty and administrative staff member	Must reflect part of the name	<<first name>>.<<last name>> <<first name>><<first character of last name>> <<initials>><<last name>>	saman.desilva samans abcdesilva
Undergraduate student accounts	Should reflect students ID and must reflect batch	<<last name>> <<initials>> . <<batch number>>   Duplicates  <<last name>> <<initials>> .<<duplicate number>> <<batch number>>	Udayanganihdn.13   Duplicates udayanganihdn2.13
Postgraduate student accounts	Should reflect students ID and must year of registration	<<last name>> <<initials>> .<<last two digits of year of registration>>   Duplicates  <<last name>> <<initials>> .<<duplicate number>> <<last two digits of year of registration>>	udayanganihdn.20   Duplicates udayanganihdn2.20
Visitor accounts including visiting lecturers and volunteers	Prefix must reflect visitor status	vl-<<first name>> vl-<<first name>>.<<last name>> vl-<<first name>><<first character of last name>> vl-<<initials>><<last name>>	vl-saman vl-saman.desilva vl-samans vl-abcdesilva
Role and task specific accounts	Must reflect role or task	<<short name of role/task>> -<<department/division>>	head-civil help-cites library
Event and project specific accounts	Must reflect event or project. Should reflect department/division	<<short name of event/project>>	exmo mercon
Systems administrator accounts	Must reflect administrator	<<admin role>>	admin mis-admin

 

 

2.4       Validity of an Account">

Valid duration of an account varies based on the type of user and anticipated duration of use as listed in Table 2.2. In addition to these maximum limits, an account may be disabled at any time by a written or e-mail request from the Head of the department/division, Examinations and Registrations division, or IT Strategy Committee. On special circumstances such as termination of a user’s service, particular account should be disabled immediately. It is solely the responsibility of the user’s superior to inform CITeS and other delegated administrators when such changes are necessary using required documentation. Moreover, CITeS and other delegated department/division level administrators may disable an account when the user poses a security or other threat to other users of the University community, the UoM, general public or to national security. After disabling, all accounts should still be retained for at least 3 months before terminating/deleting from the system(s). All user access will be reviewed no less than annually for critical information systems.

 

Table 2.2 - Validity period of an account.

 

Account Type	Valid Period
Faculty and administrative staff member	3 months after retirement, transfer, change of role, or resign.
Undergraduate student accounts	3 months after graduation or end of normal duration
Postgraduate student accounts	3 months  after graduation or end of normal duration
Visitor accounts including visiting lecturers	3 months for visiting lecturers and 1-month for all other visitors
Role and task specific accounts	3 months from the date the role or task becomes invalid.
Event and project specific accounts	3 months after even or end of projects. Valid period is not defined to annual events or projects.
Systems administrator accounts	System lifetime

 

 

Alternatively, an account may automatically get disabled or locked out at least for one hour, where a password for an account has been entered incorrectly at least three (3) consecutive times.

 

3.0   Passwords

Users’ access to UoM IT facilities is usually protected by a password, which is a secret string of letters, numbers, and/or symbols that is used to prove the identity/username of a user. Therefore, it is strictly required that:

1. Users must not divulge their passwords to anyone including CITeS and other administrative staff
2. Disclosed of user name and passwords to anyone by students would be a punishable offense
3. Users should not reveal passwords via e-mail and phone, as well as not cache using remember password feature of applications such as web browsers and mobile apps
4. Users who have access to multiple user accounts (depending on their role and services being accessed), should not use the same password across different University and non-University user accounts
5. Users must not knowingly engage in any activity to obtain the passwords of other users
6. Users must access UoM IT facilities using only their usernames
7. A user must immediately change his or her password and inform the relevant systems administrator if a password compromise is suspected
8. Users must follow the guidelines provided by the relevant systems administrators and University password policy in selecting and keeping a secure password and logging-off after use of IT services

 

In addition to passwords, other forms of authentication such as fingerprints, access cards and tokens (magnetic strip and NFC based ones), device signing, and digital certificates may be used for specialized applications. In such cases, due care should be used to issue, transfer, use, and store those credentials similar to that of a password. In future, two-factor authentication must be used for administration of business-critical and sensitive systems such as LMS, MIS, and accounting and HR. By 2021, two-factor authentication should be used for all access to University IT facilities initiated from outside the campus.">

 

3.1       Password Complexity">

A password should be an alphanumeric string consists of characters, numbers, and symbols in the format specified in Table 3.1. Moreover, an acceptable password for an account must also satisfy the following requirements:

1. Not be a password that is one of the three (3) most recently used passwords for that account
2. Must not be derived directly out of user’s Personally Identifiable Information (PII) such as part of the name, birth year, phone no, index no, or program being followed
3. Must not be a word related to the University or department such as Moratuwa, UoM, mrt, Mora, or Katubedda
4. Must not be a dictionary word, slang, dialect, or jargon

All information systems should be configured to enforce all initial and renewed passwords satisfy this policy.

 

 

 

 

Table 3.1 - Password complexity matrix.

Account Type	Minimum Length	Combination	Change Frequency	Reset Mechanism
Faculty and administrative staff member	8	At least 1 uppercase (A-Z) and one lowercase (a-z) character, 1 number (0-9), and 1 symbol	3 years	Self-service reset via MIS if valid mobile and secondary e-mail are set up at the time of registering. At service desk with Photo ID or on written request of user and approved by Head of department/division
Undergraduate student accounts			Not required	Self-service reset via MIS if valid mobile and secondary e-mail are set up at the time of registering. At service desk with Photo ID
Postgraduate student accounts
Visitor accounts including visiting lecturers			Annual	Self-service reset via MIS if valid mobile and secondary e-mail are set up at the time of registering. At service desk or on written request of respective Head of department/division
Role and task specific accounts			180 days	On written request of respective head of department
Event and project specific accounts
Systems Administrators	12		Annual	At service desk with Photo ID or on written request of user and approved by Head of department/division
Systems Accounts / Superuser User			180 days	By superuser
Passwords used to protect encryption keys	15		Annual

 

 

3.2       Initial Passwords

When a user account is created the user should be given a random password as per the password complexity defined in Table 3.1. Users should be prompted to change this password at the time of the first login to the respective system. The initial/first-time password should expire in 72 hours. If the user does not login within 72-hours from the generation of new password, account should be automatically disabled/locked. In such cases, user needs to request a new password following the procedure outlined in Section 3.4.

 

3.3       Transfer of Passwords

Newly generated passwords should be shared with the user only at the service desk, as a text message to his/her phone number, or e-mail. The phone number or e-mail should be the one specified in the user account request as per Section 2.2. No password should be shared with the user in the written form, and all forms of digital transmissions should be over an encrypted channel.

 

3.4       Changing Passwords

Depending on the account type information systems should prompt the user to renew the password as per the password change frequency defined in Table 3.1. Users may also change the password themselves from time to time, which is highly encouraged to keep the IT facilities secure.

In case a user has forgotten or lost the password, he/she could request CITeS and delegated administrators to reset the password. To reset a password should provide a valid photo ID such as the staff ID, student ID, and NIC to the service desk as specified in Table 3.1. Only the owner of a user account shall be allowed to request the password to be changed. The only exception shall be when the owner of the user account has been incapacitated or left the organization, in which case the relevant head of the department/division can request that the password is changed. For certain types of users, especially where a photo ID cannot be presented (e.g., role, task, event, and project-specific accounts) the respective Head of the department/division may request that the password is changed. In both the cases, the request must be either given in writing or should be initiated via the official e-mail address. The administration staff may reset the password only upon satisfactory confirmation of the photo ID or written request. In all cases, the renewed password should satisfy the password complexity matrix in Table 3.1 and should be treated similarly to an initial password and user shall be required to change their password at first subsequent login as outlined in Section 3.2.

 

3.5       Storage of Passwords and Other Credentials

All password and other credentials such as fingerprint data and digital certificates should be securely stored as per the details outlined in the Information Security Policy. Moreover, all passwords in digital form should be stored as one-way passwords that are hashed with a random salt. No password should be kept in clear text either digitally on in written form.