Standard for Account and Authentication Management

Introduction

The management of user accounts and the authentication methods associated with them are critical to the protection of The New School’s Institutional Information and IT Resources.

Purpose

This standard defines the minimum requirements for the management of user accounts and the authentication methods used to control access to New School systems.

Scope

This standard applies to all accounts, passwords, and other authentication methods used to access university systems that are used to Process Institutional Information, irrespective of whether they are maintained by The New School or a third party on the university’s behalf or whether they are accessed from on-campus or off-campus locations, and to any Workforce Member or other authorized individual who accesses or in any way makes use of them, regardless of affiliation.

A “system” is any IT Resource to which the safeguards described in this standard can be applied. Examples of systems include, but are not limited to:

• Desktop, laptop, or server computers (including virtual servers) running general-purpose operating systems such as Windows, Mac OS X, and Linux
• Mobile devices (e.g., phones, tablets) to the extent they interact with New School resources and systems, such as New School G Suite, Banner, Workday, etc.
• Web-based applications (generally, any application accessed via a web browser)
• Client-server applications (generally, any application using a “fat” client)
• Network server applications, such as a VPN or an FTP server
• Databases

This standard does not apply to:

• End-user devices owned and used by students for purposes of attending the university and completing coursework
• End-user devices owned and used by the general public (i.e., individuals unaffiliated with the university)
• Students who are not Workforce Members

Definitions

Special terms used in this document will be Capitalized and underlined, signifying that they have special meaning. A comprehensive glossary of terms, with examples, can be found at https://ispo.newschool.edu/glossary/.

Requirements

The controls and control values specified by this standard represent minimum requirements that must be implemented by all systems. At the reasonable discretion of the Application Owner or Data Owner, or when recommended by a risk assessment, more restrictive controls may be implemented.

In the event that a system cannot be configured exactly as specified by this standard because it does not provide the necessary controls or control values, the settings that are provided must be configured to match the specifications of this standard as closely as possible. If the resulting level of security is significantly different than the level defined by this standard, and the system will be used to Process information Classified at Protection Level PL-3 or higher, a risk assessment must be performed to determine whether compensating controls are needed.

Use of identity stores

Wherever possible, enterprise identity stores (TNS Active Directory and, in some circumstances, Luminis LDAP) must be used to grant access to systems and to authenticate users. The use of local or system-specific identity stores, such as password files or database tables, to store authentication data is permitted only as a last resort.

Note

This requirement applies only to the storage of “coarse-grained” access control information (i.e., whether or not the user may even access or sign on to the system) and primary authentication information (e.g., passwords). “Fine-grained” access control information, such as user permissions governing access to specific system functionality, may (and in most cases should) be stored in local or system-specific data stores.

Query methods

The preferred method for web-based systems to query the enterprise identity stores is to configure them to use the New School Single Sign-On (SSO) service via either the CAS or SAML2 protocols. The SSO service handles authentication against all enterprise identity stores, makes standard user attributes (name, email address, etc.) available to the calling system, handles multifactor authentication when required, and directs users to password change/reset links if needed.

Systems that cannot be configured to use the SSO service should use either Active Directory Service Interfaces (ADSI), or the Lightweight Directory Access Protocol (LDAP):

• When using ADSI, Kerberos-based or TLS-based encryption should be used to provide data confidentiality and integrity. Unencrypted ADSI should be used only as a last resort, and must never be used over the Internet or DMZ networks. NTLM-based encryption is not secure and should be avoided, although it is still preferable to no encryption at all.
• When using LDAP, LDAPS (TCP Port 636) or the LDAPv3 StartTLS directive should be used to provide data confidentiality and integrity. Unencrypted LDAP should be used only as a last resort, and must never be used over the Internet or DMZ networks.

Local identity stores

Many systems require the use of a local identity store to maintain information about authorized users of the system such as user profiles and system-specific user permissions. When a system requires this, the following requirements must be met:

1. The local identity store must be synchronized with an appropriate enterprise identity store; for the remainder of this section this shall be referred to as the primary identity store.
2. Usernames must be created in the primary identity store before they can be copied to the local identity store; this ensures that username formatting conventions and uniqueness requirements can be enforced.
3. A process must be established to periodically reconcile information about users between the primary identity store and the local identity store. Generally, this will be a one-way process with information from the primary identity store overriding information in the local identity store.
4. A process must be established to ensure that when a user is locked or disabled in the primary identity store this action immediately carries over to the local identity store.
5. A process must be established to ensure that when a user is deleted from the primary identity store the user is also deleted from (or disabled in) the local identity store.
6. User authentication must be performed against either New School SSO or a primary identity store (see above); the local identity store should not contain user authentication data (i.e., passwords).

Note

The above requirements do not apply to internal-to-the-system users such as the user used to configure and operate the system (often called admin or similar). These users do not have to be synchronized with enterprise directories, and the system may store the passwords for these users locally. Note, however, that all other applicable controls in this standard (password complexity, password aging, inactivity timeouts, etc.) must still be implemented for these users.

User identification

As a means of controlling access to IT Resources and Institutional Information and maintaining accountability, each user must be uniquely and unambiguously identifiable. The New School assigns every individual—faculty, staff, or student—a unique identifier, called a NetID, when the individual first becomes part of the New School community. The NetID is unique for all time; even after an individual has left the university it will never be reassigned to somebody else. There are certain situations in which an individual may be assigned a new NetID (e.g., a legal name change), but when this occurs, the original NetID will be retired and not re-used.

• The NetID must be used as an individual’s username by all systems where such use is possible.
• The NetID also forms part of the official New School email address for the user: netid@newschool.edu. The official New School email address should be used as an individual’s username by any system that requires an email address for that purpose.
• The New School allows, but does not require, users to choose an email alias (e.g., first.last@newschool.edu). The alias is not a separate email account; it is a second address that may be used to send and receive email from/to the same mailbox that is attached to the official email address. A user may have only one (if any) alias in effect at a time. Therefore, to choose a new alias, the user must first relinquish the old one, which makes it available for someone else to choose. Because email aliases may be re-used and may be assigned to different individuals at different times, their use as usernames should be avoided.

The New School N-number, although also a unique identifier that is never reassigned, is not a public identifier (it is classified at Protection Level PL-3). Therefore, N-numbers may not be used as usernames. Any exception to this must be approved in advance by both the Office of the Registrar and the Information Security and Privacy Office.

User authentication

Use of initial passwords

The use of initial passwords (i.e., a password generated by the system and then communicated to the user) is discouraged. A better approach is to generate a random password for the user that is never communicated to anyone, and then require the user to reset that password (going through the appropriate user verification steps in the process) to access the account.

Where the use of initial passwords is necessary, the user must be prompted to change the initial password immediately upon first use, before being granted access to the system.

Minimum length of passwords and PINs

Passwords must contain a minimum number of characters:

Account Type	Minimum Length
Functional Account	8 characters
Service Account	12 characters
Privileged Account	12 characters
User Account	8 characters
Voicemail Account	4 digits (Numeric PIN)

The minimum password length for any account type not listed above is 8 characters. The minimum PIN length for any account type not listed above is 6 digits.

Complexity requirements for passwords and PINs

Passwords must contain characters from at least three of the following four character classes:

• Uppercase letters: A through Z
• Lowercase letters: a through z
• Base 10 digits: 0 through 9
• Non-alphanumeric characters: ~!@#$%^&*_-+=\`|\(){}[]:;"'<>,.?/ and <space>

Any system may, for technical reasons, refuse to allow certain characters in passwords (e.g., characters that may cause parsing errors leading to code injection vulnerabilities). For example, web-based applications will often refuse to accept <space> and database-backed applications will often refuse to accept characters that have special meaning in SQL statements.

Passwords may not contain the username, or elements of the user’s full name exceeding two characters in length.

Maximum age (password expiration)

Passwords must be changed periodically:

Account Type	Maximum Age
Functional Account	180 days
Service Account	No Maximum
Privileged Account	180 days
User Account	180 days
Voicemail Account	No Maximum
Built-in administrator or super-user accounts	No Maximum

The maximum password age for any account type not listed above is No Maximum. At the reasonable discretion of the Application Owner or Data Owner, or when recommended by a risk assessment, a system may be configured with lower (but not higher) maximums than the above.

Note

For avoidance of doubt, it is not a violation of this standard for a system to implement a lower maximum (e.g., 90 days instead of 180 days).

Once the maximum password age has been reached, the password expires (preventing login) and must be reset before the account can be used.

Built-in administrator and super-user accounts and Service Accounts are not subject to password aging because of the risk that a password will expire and interrupt the operation of a mission-critical service or make it impossible (or extraordinarily difficult) to access a mission-critical resource.

Minimum age (time between password changes)

Passwords must be in effect for a certain amount of time before they may be changed:

Account Type	Minimum Age
Functional Account	1 day
Service Account	No Minimum
Privileged Account	1 day
User Account	1 day
Voicemail Account	No Minimum
Built-in administrator or super-user accounts	No Minimum

The minimum password age for any account type not listed above is No Minimum. At the reasonable discretion of the Application Owner or Data Owner, or when recommended by a risk assessment, a system may be configured with higher (but not lower) minimums than the above.

Note

For avoidance of doubt, it is not a violation of this standard for a system to implement a higher minimum (e.g., 2 days instead of 1 day).

Once a password has been changed, it may not be changed again until the minimum age has been reached. The intent of the minimum age is to prevent users from quickly cycling through passwords in an attempt to defeat the password history requirement and re-use a familiar password.

Built-in administrator and super-user accounts are exempt from the minimum password age requirement; these accounts should be able to change any password in the system at any time.

Password expiration notification

Users whose passwords are about to expire must be warned that their passwords are about to expire. The warning may be displayed to the user at the time they log in or sent to the user via electronic mail. The latter is preferred, to avoid the situation in which a user does not sign on to the system often enough to see any of the warnings.

To the extent supported by the system, warnings must be delivered on the following schedule, as adjusted for “appropriateness” depending on the maximum password age (expiration period):

• 14 days before the password expires (if appropriate)
• 7 days before the password expires (if appropriate)
• 3 days before the password expires
• 2 days before the password expires
• 1 day before the password expires

Password history

Enterprise identity stores, and systems that implement local identity stores, must maintain a list of previously-used passwords for each user, and prevent users from re-using their last 7 passwords.

Built-in administrator and super-user accounts are exempt from the password history requirement; these accounts should be able to (re)set a password to any value, even one that has been used before.

Security questions

Security questions, such as “name your kindergarten teacher,” “what is your favorite color,” or “what was the name of your first pet” are difficult to design in such a way that they have one definitive unambiguous answer that the user would never forget, yet are secret and hard to guess for everybody else. This is further complicated by the diversity of national, cultural, and linguistic backgrounds represented by the New School community; great care must be taken to create questions that are both meaningful to everyone and not offensive to anyone.

This standard does not prohibit the use of security questions, but for the reasons described above, their use is strongly discouraged.

Multifactor authentication

Systems that are accessible via the Internet (without requiring a VPN) and used to Process Institutional Information Classified at Protection Level PL-4 must require users to provide a second authentication factor in addition to their username and password. This multifactor authentication requirement may be implemented by:

1. The New School Single Sign-On service, using the New School official multifactor authentication solution (preferred).
2. The system itself using its own native support for the New School official multifactor authentication solution (second choice).
3. The system itself using some other multifactor authentication solution (last resort).

The New School official multifactor authentication solution is the one offered at 2step.newschool.edu.

At the reasonable discretion of the Application Owner or Data Owner, or when recommended by a risk assessment, any other system may also be configured to use multifactor authentication.

Sign-on process

Automatic sign-on

Systems must not permit users to sign on without entering their authentication credentials. Wherever permitted by the system, features that provide this type of functionality must be disabled.

Notes

1. This requirement does not apply to applications using the New School Single Sign-on service (which is designed to provide this functionality securely).
2. This requirement does not apply to classroom computers that are configured to start in an already-logged-in state (it does, however, apply to computers in the open labs).
3. This requirement does not apply to kiosk systems in New School libraries.

“Remember me” features

Systems must not permit a user to save (“remember”) passwords or other authenticators so that they can be used to sign on automatically to other systems. Wherever permitted by the system, features that provide this type of functionality must be disabled.

The implementation of this requirement on Internet web browsers is especially critical. Wherever possible all “save password” and “remember this password” functionality, including built-in password managers, must be disabled in web browsers installed by The New School on university-owned computers.

Notes

1. This requirement does not apply to software that is installed by the individual user (e.g., an alternative web browser), as there is no practical way to implement it in that situation.
2. This requirement is not intended to preclude the use of password manager applications, which store passwords in an encrypted format protected by a key known only to the user.

Account lockout and wait period

The Active Directory account lockout policy must be configured as recommended by Active Directory: Account Lockout Policy—Think Twice Before Applying:

Setting	Value
Account lockout duration	5 minutes
Account lockout threshold	50 invalid logon attempts
Reset account lockout counter after	1 minute

For systems that do not use the New School Single Sign-on service or TNS Active Directory to authenticate users, accounts must be locked out (requiring reset by an administrator, a self-service portal, or an automated process) after 5 consecutive authentication failures. An account that has been locked out due to excessive authentication failures may be automatically re-enabled after a minimum wait period of 15 minutes (it may be manually re-enabled by the user or an administrator at any time).

Notes

1. This requirement does not apply to built-in administrator and super-user accounts unless the system provides a practical procedure to regain access to the system or application (by resetting the lock or otherwise).
2. An acceptable alternative to this control is one that implements a progressively longer and longer delay between password prompts after each failed attempt. The delay must not be reset to zero until a successful authentication occurs.

Re-authentication on system wake/resume

When a system resumes from a “sleep” or “hibernate” state, the signed-on user (if any) must be prompted to re-enter their password. If the system is also configured to require multifactor authentication as part of the normal sign-on process, then the user should also be required to compete a new multifactor sequence.

Idle (inactive) sessions

Interactive local sessions that have been idle (inactive) for 15 minutes (2 minutes on mobile devices) must revert to a locked user interface or locking screen saver that requires the user to re-enter their authentication information (password, pattern, or two-factor) to resume the session. Systems that cannot be configured to “lock” an idle user session must be configured to terminate the session instead.

Notes

1. Some screen savers provide a “grace period” between invocation of the screen saver and locking of the console. Where this functionality is present, it must be disabled (preferred) or set to 0 seconds.
2. Some screen servers allow themselves to be temporarily disabled by moving the mouse cursor to a particular location (usually a corner) on the screen. Where this functionality is present, it must be disabled.
3. This requirement does not apply to classroom systems, systems in the open computer labs, or New School Library kiosk systems.

Interactive remote sessions connected to systems that Process Institutional Information Classified at Protection Level PL-3 or higher must revert to a “locked” state after more than 30 minutes of idle time (inactivity), requiring the user to re-enter their authentication information (password, pattern, or two-factor) to resume the session. Systems that cannot be configured to “lock” an idle user session must be configured to terminate the session instead.

Account and credential management

Managing default (built-in) accounts

Default or built-in accounts (well-known usernames and passwords provided by system vendors) that are necessary to the correct operation and/or administration of a system must have their passwords changed at the time the system is installed. The new password must be selected in accordance with the user authentication requirements established by this standard.

Default or built-in accounts that are not necessary to the correct operation or administration of a system must be disabled if possible. If the system does not provide a method to disable them, their passwords should be set to randomly-generated values that meet the user authentication requirements established by this standard, and then any record of the values should be destroyed.

Ownership of Functional and Service Accounts

Each Functional Account and Service Account must have a designated owner who is responsible and accountable for the management and appropriate protection of account credentials and access. The Functional Account or Service Account owner must document:

• The purpose of the account
• A list of all individuals who have access to the account
• All use cases involving use of the Functional Account
• The IT Resources that depend on the Service Account

Management of Service Accounts

Service Accounts, especially those used to Process Institutional Information Classified at Protection Level PL-3 and higher, must be disabled for interactive login or screen/user interface sessions when possible.

Service Accounts essential to the operation of a system must be accessible to more than one Workforce Member. In practice, this requirement implies that usernames and passwords for all Service Accounts must be stored in the Information Technology department’s password management system.

Management of Privileged Accounts

Wherever possible, every privileged user of a system should be given their own Privileged Account to perform installations, updates, and other maintenance activities on the system. Use of individually-assigned Privileged Accounts facilitates activity logging and the preservation of responsibility and accountability.

Privileged Accounts may only be used for tasks that require privileged access to a system; they should not be used for day-to-day tasks (e.g., email, web browsing, etc.).

Sharing passwords, PINs, authentication devices

Workforce Members must not share account passwords, passphrases, PINs, devices used for authentication (e.g., mobile phones), or tokens (e.g., multifactor tokens, smartcards) with others.

Note

This prohibition does not apply to Functional Accounts which, by their nature, are meant to be shared by multiple Workforce Members. However, alternative methods of providing access to the Functional Account’s resources (e.g., mailbox delegation, group membership) that do not require the account’s password to be shared should be considered and used where possible.

Requesting passwords from users

University business processes must not request or require individuals to disclose or share the password or passphrase to a User Account (e.g., as a condition of enrollment or employment, or to provide technical support).

Review

This standard is reviewed on a periodic basis and updated as necessary by the Information Security and Privacy Office to ensure it remains accurate, relevant, and fit for purpose.

Document history

Date	Author	Description
Jun 2020	D. Curry	Initial publication
Aug 2020	D. Curry	Replaced oppressive and gender-specific terms with better alternatives

Parts of this standard are adapted from the University of California’s Account and Authentication Management Standard, coordinated by Robert Smith, the contents of which are used with permission.