Go to navigation (press enter key)Menu

Password Policy

This password policy is consistent with our current best practices and will be enforced in our systems with the launch of our Identity & Access Management System (IAM), tentatively scheduled for Fall 2015.

Vassar College Password Policy

Vassar College issues an online account to each individual as they join the College community. This account is used to access email, the learning management system, perform financial transactions with the College, and many other services. As such, the account is a privilege with its usage governed by Vassar’s Responsible Use Policy and this Password Policy. Members of the Vassar community must be familiar with each of these policies.

1. Overview

1.1 Purpose and Rationale

Passwords are an important part of Vassar's efforts to protect its technology systems and information assets by ensuring that only approved individuals can access these systems and assets. Advances in Information Security research has led to the development of new best practices for the composition, lifetime and general usage of passwords. This policy is designed to adopt these practices to enhance the security of the Vassar community.

1.2 People Affected

All members of the Vassar community (including contractors and temporary staff) who are approved to access College systems or information. The term ‘client’ is used to refer to all Vassar community members. System developers, system administrators and service desk staff have specific additional responsibilities.

Notes:

  • Passwords for system administrator accounts (such as root on Unix systems) will be covered by a separate High-Risk System Access Policy.
  • External clients (customers, business partners and the like) will follow similar policies attached to the appropriate contractual terms and conditions or equivalent.

1.3 People Responsible

The people responsible for communicating, implementing, enforcing, and changing this policy are:

  • Chief Information Officer - Michael Cato
  • Vice President for Finance and Chief Financial Officer - Robert Walton

1.4 Structure of Policy

  • Principles
  • Responsibilities
    • Clients
    • Service Desk Staff
    • System Developer and Administrator

1.5 Language

In the "Responsibilities" sections of this policy, the keywords "must," "must not," "should," "should not" and "may" are to be interpreted as follows:

  • "Must" means that the statement is an absolute requirement of the policy.
  • "Must not" means that the statement is an absolute prohibition of the policy.
  • "Should" means that there may exist valid reasons in particular circumstances to ignore a particular statement, but the full implications must be understood and carefully weighed before choosing a different course.
  • "Should not" means that there may exist valid reasons in particular circumstances when the particular action is acceptable or even useful, but the full implications should be understood and the case carefully weighed before acting in a way described with this label.
  • "May" means that a statement is truly optional.
Top

2. Principles

2.1 Password Confidentiality

To provide authentication effectively, it is essential that a password be known to only the individual client. Clients must ensure the confidentiality of their passwords at all times. System developers and administrators must not allow systems to store passwords in clear text.

Administrative processes may necessitate temporary exceptions to this principle, but these must be kept to an absolute minimum.

2.2 Password Construction

To resist common kinds of attacks, a password must meet minimum requirements. Because of technology constraints, password construction rules may vary from one system to another, but they should meet (or exceed) these requirements wherever possible.

Though this may appear counterintuitive, recent research has shown long passwords, even when constructed from simple words, such as “correcthorsebatterystaple”, are demonstrably stronger, easier to remember, and thus harder to attack by social engineering. This is a departure from the historical preference for passwords that are shorter in length and rely on a mixture of character types such as “SuperHer0!”.

Vassar recognizes that long and complex passwords may be difficult for clients to create and remember, and thus, this policy provides guidance to clients on how to construct a memorable password that meets (or exceeds) these requirements.

Password Construction Rules

  1. A password must be 15 or more characters in length and can be constructed by combining three or four random words of five or more letters.
  2. A password must not include the client’s username.
  3. A password must not be a simple variation of a previously used password.
  4. A password should not include anything that is immediately identifiable to the client, such as a name (either real or fictional), the client’s department/group name, a date (such as family birthdays and anniversaries), telephone numbers, postal codes, car registration numbers and so on.

2.3 Password Change and Reuse

  • To minimize the window of opportunity for an attacker who has discovered a client's password, clients will be required to change their passwords periodically.
  • A client's new password must be completely different from any recently used password.
  • A client must be free to choose a new password at any time, but a client must not perform multiple changes in quick succession in order to enable continued use of a recently used password.

Password Change and Reuse Rules

  1. A client must change his or her password at least once per year.
  2. A client's password must be different from his or her previous six (6) passwords.
  3. A client's password must not have more than three contiguous characters in the same position as his or her previous password.
  4. A client should not change his or her password more than twice in three (3) days.

2.4 Password Entry

  • The password field in a login panel must be configured to obfuscate the password entered by a client to minimize the risk of opportunistic observation by another.
  • A system must allow multiple successive login attempts ("grace logins"). If the password is not correct on the last allowed attempt, then the client's account must be suspended, and the client will have to contact the Service Desk to resume the account and, if necessary, reset the password.

Password Entry Rules

  • A system must allow ten (10) grace logins.

2.5 Password Storage

  • A system must not hold passwords in clear text.
  • A system must use an approved, irreversible cryptographic transform to protect its clients' passwords.
  • A system that stores clients' passwords for other systems and brokers those passwords to those systems on behalf of the client must use an approved (reversible) encryption algorithm.
Top

3. Client Responsibilities

As a member of the Vassar community you have the following responsibilities regarding the password you use on any of Vassar's systems. (See section 1 Language for the meanings of the terms in bold type.)

Note that these responsibilities apply, even if the system does not enforce any specified rules.

  • You must choose a password of at least 15 characters that meets or exceeds the requirements set out in section 2.2 Password Construction Rules.
  • You must change your password at least once per year.
  • You must keep your password confidential at all times.
  • You must not disclose your password to anyone, including Vassar's management and technical support staff, even if they demand it. If this happens, you must escalate to the Senior Officer for your area immediately.
    • The only exception is disclosure as part of a duly executed legal action with the guidance of the Vice President for Finance and Administration or the Senior Officer with responsibility for your area.
  • You must not use any of your previous six (6) passwords.
  • You should not use any password that you use on any Vassar systems on any external system (including Internet banking and social networking services).
  • You should not write down your password.
  • You should not change your password more than twice in any three (3) days.

Tips for Choosing a Good Password

A long password can be constructed relatively easily by linking together random simple words.

As examples:

  • correcthorsebatterystaple
  • corksafarilampsgolf
  • geesefurnacesnowflake

Try to avoid common phrases or word pairings within your password such as:

  • gingerbreadlatte
  • hotoffthestove
Top

4. Service Desk Staff Responsibilities

If you are a Vassar Service desk operator, or a system administrator providing support normally done by the Service desk, you have the following responsibilities regarding clients' passwords on any of Vassar's systems that you support. (See section 1.5 Language for the meanings of the terms in bold type.)

  • When a client asks you to reset his or her password, you must corroborate the client's claimed identity in line with approved procedures.
  • You must not disclose a client's new password to anyone other than the client himself or herself.
  • You must not write down a client's new password.
  • You must not send any new password to a client electronically.
  • You must not ask any client to tell you his or her password.
Top

5. System Developer and Administrator Responsibilities

If you are a system developer or system administrator, then you have the following responsibilities regarding the clients passwords on any of Vassar's systems that you own, develop or maintain. (See section 1.5 Language for the meanings of the terms in bold type.)

  • You must configure each system to require that any client's password meets the length and complexity requirements set out in section 2 Password Construction Rules.
    • If this is not technically feasible because of system constraints, contact the Chief Information Officer to agree on and document the exception.
  • You must configure each system to require a client to change his or her password according to the section 2 Password Change and Reuse Rules.
    • If this is not technically feasible because of system constraints, contact the Chief Information Officer to agree on and document the exception.
  • You must configure each system to require that any client's password meets as many of the other requirements set out in section 2 Password Construction Rules as are technically feasible.
  • You must configure the password field in a login panel to obfuscate the password entered by a client to minimize the risk of opportunistic observation by another.
    • If this is not technically feasible because of system constraints, contact the Chief Information Officer to agree on and document the exception.
  • You must configure each system to allow ten (10) successive login attempts ("grace logins"). If the password is not correct on the tenth attempt, the system must suspend the client's account such that the client will have to contact an administrator to resume the account and, if necessary, reset the password.
    • If this is not technically feasible because of system constraints, contact the Chief Information Officer to agree on and document the exception.
  • You must implement an approved cryptographic transform to protect the passwords of the clients on each system.
  • You must implement an approved (reversible) encryption algorithm in any system that stores clients' passwords for other systems, and brokers those passwords to those systems on behalf of the client.
  • You must configure each system to prohibit a client from using any of his or her previous six (6) passwords.
  • You must configure each system to prohibit a client from changing his or her password more than twice in any three (3) days.
  • You must not implement reversible encryption to protect the passwords of the clients on each system, except where the password itself is used as a key to encrypt a fixed value unique to each client (for example, the client's client ID) using an approved encryption algorithm.

5.1 Requirements for Third-Party Systems

All mandatory requirements noted in this section (that is, those denoted by "must" or "must not") comprise part of the minimum security specification for third-party system software that Vassar acquires and implements. That is, it is essential that system software enables system developers and administrators to fulfill these responsibilities.

If a third-party system cannot meet the minimum security specification, contact the Chief Information Officer to agree on and document the exception.

All optional requirements noted in this section comprise desirable features of third-party system software.

Top

7. Revision History

Initially Approved - February 10, 2015

Top