Preamble
This document outlines the complexity requirements and proper management practices of passwords for all computer systems at the University of Waterloo. It is expected that all members of the University of Waterloo community abide by these standards.
Contents
- Complexity requirements
- Aging requirements
- Lockout requirements
- Breach of a password
- Practices for end users
- Practices for IT Support Staff
- Password audits
Complexity requirements
Effective November 27, 2024, password complexity requirements (e.g., including a digit, uppercase character, special character) are being removed in favour of longer passphrases. Password standards will be updated as follows:
- Minimum length: 15 characters
- Maximum length: 64 characters
- Other: does not contain the individual’s name or other University of Waterloo identifier
Current password complexity rules for privileged accounts in NEXUS (e.g., !) will remain in force with the minimum length adjusted to 15 characters.
Aging requirements
- Maximum password age: none
- Minimum password age: 1 day
Please note that a password age of 126 days (approximately one academic term) is strongly recommended for accounts that have access to information classified as Highly Restricted, unless the information belongs to the owner of the account. Ideally, the same practice should be followed when Restricted information is involved. See Policy 46 for the definitions of Highly Restricted and Restricted information.
For example, an account belonging to a student, to access his/her university records, does not have any password aging requirements where an account belonging to a staff/faculty member, with access to student information, should have the recommended password age.
Lockout requirements
- Account lockout duration: 5 minutes
- Account lockout threshold: 50 failed attempts
- Reset account lockout counter after: 5 minutes
Breach of a password
A password is classified as Restricted in Policy 46, so a password breach is subject to the Information Security Breach Response Procedure.
Practices for end users
Choosing good passwords
A good password has the following properties:
- It's long enough to resist automated guessing (the longer, the better).
- It's easy to remember.
In order to satisfy these two requirements, it helps to think of passwords as passphrases instead. Good passphrases contain at least 4 unique words, include some numbers and punctuation, and be at least 15 characters in length. An example of a good passphrase:
Vision 2020, when the geese attack.
Note that while the use of dictionary words in a password is discouraged, the use of dictionary words in passphrases that are longer than 14 characters, where the passphrase meets complexity requirements, should be OK.
Shared passwords
Unless the account is a generic, shared account, a password must not be shared. Shared/Generic accounts should be used only when absolutely necessary to solve a business need. There are usually methods to solve a business need without the use of an account with a shared password.
Users with access/responsibility for other accounts, such as generic or privileged accounts, must use a unique password for each account.
Password security
A password should never be revealed to anyone, by any means. Supervisors and IT support staff who need access to an account can do so by other means.
Managing/remembering multiple passwords
Writing down your password is OK, as long as you make sure that:
- You don't write down anything that attributes the password to the userid or purpose of the account.
- You keep the password secure. (e.g., either in your wallet or under lock and key)
- You make an effort to remember the password so that you can destroy the paper copy.
Some people store passwords in a file on their computer. If you do this, you must ensure the file is encrypted, and that the encryption key is well protected.
Browser caching of passwords
All modern web browsers provide a facility to remember passwords to access-controlled web sites. Since there are methods of exploiting the browser cache of passwords, it is strongly recommended that the browser feature to remember passwords be disabled, especially on mobile devices.
Practices for IT Support Staff
Setting initial passwords
When setting an initial password for a user, the password should be a unique random string that's generated dynamically (e.g., by using the apg program). If the initial password is some other identifier that is not random, then a mechanism needs to be in place so that accounts are disabled if the initial password has not changed within two weeks. Any account where the initial password has not changed within six weeks should be disabled.
Use of Central Web Authentication Service
Any information system that provides web-based services to students, faculty, and/or staff, should use Waterloo's central web authentication service. This service, currently implemented with Active Directory Federation Services (ADFS), provides several benefits, including:
- Better user experience
- The single sign-on functionality allows a user to use multiple applications by only authenticating once.
- Better Security
- Fewer web sites prompting for credentials means a smaller attack surface for brute-force password cracking. This also facilitates the throttling of an attack in one place.
- Users trained to type credentials only to the central authentication service are less susceptible to being victims of phishing.
- Account compromises are easier to detect since the authentication always happens at the central service.
- User passwords are harder to capture as a result of a web server compromise.
Managing passwords for service accounts
Staff responsible for service accounts should keep an inventory of these accounts. Every service account must have a unique password. A service account password must be changed as soon as reasonably practical after any staffing change involving a person who has had access to the service account password. Service account password changes should be treated like any other system change by using appropriate change control processes.
Local administrator accounts
It is common for systems administrators to create images of operating systems for deployment to multiple workstations and/or servers. Whether these hosts are in an Active Directory domain, or make use of externalized authentication such as RADIUS or LDAP, they will have a privileged local account. The management of these local accounts is often overlooked. Mechanisms should be in place so that the passwords of local privileged accounts are changed on a regular basis.
Password storage
On Unix/Linux systems, the crypt password hashing scheme must be avoided in favour of SHA-2, Blowfish, or MD5 (with salt). On Windows systems, LANMAN hashing must be disabled.
Passwords for High Security Applications
While more expensive to implement and manage, multi-factor authentication should be used in favour of static passwords for high security applications.
Password audits
All members of the University of Waterloo community should expect that any password used to access University of Waterloo computing resources be subject to regular audits. Password audits may be performed by authorized persons as follows:
- In the case of a standalone host or service, the system administrator of that host or service.
- Information Systems & Technology (IST) staff, under the direction of the Director, Information Security Services.
- Audit professionals authorized by the information steward and/or the university administration.
The discovery of a weak password should be communicated to the person responsible for the associated account. What constitutes a weak password will change over time and will depend on ever-changing technology and risk.