Password and Authentication Standard

Overview

Promoting secure access to UA systems, services, and data relies on strong digital identity authentication, with passwords playing a key role. Passwords help protect data confidentiality and are the responsibility of their respective account holders. They are used across UA for various accounts, including user, system, service, and email accounts, as well as for accessing specialized applications.

Scope

This standard applies to all individuals who have (or are responsible for) an account or access that supports or requires a password. This includes all faculty, staff, students, sponsored accounts, affiliate, and service accounts.  This standard is particularly applicable to :

  • All university computer and networked  systems, including any externally hosted systems that are integrated with UA login mechanisms;
  • All individuals that create, process, maintain, transmit, or store sensitive institutional data on any device, regardless of ownership (including personal devices) or whether it is connected to UA networks;
  • Any third-party providers in a contractual relationship with the university that maintains sensitive UA data.

Definitions

  • Assurance
    The confidence or trust that security measures are effectively protecting systems, data, or processes from threats.
  • Authenticator
    The tool or method used to prove your identity during authentication that is unique to you as an individual. It can be something you know (like a password), something you have (like a phone or security token), or something you are (like your fingerprint or face). The authenticator helps confirm that you’re really you before granting access to a system or service.
  • Secret
    Any sensitive information that needs to be kept confidential to protect systems, data, or processes. This can include things like passwords, encryption keys, API tokens, or any piece of data that grants access to secure systems.
  • Service Account
    A special type of account used by applications, services, or automated processes, rather than a human user. These accounts are typically used to run software, perform background tasks, or interact with other systems securely. Service accounts often have elevated privileges to access specific resources, making it important to manage and secure them properly to prevent unauthorized access or misuse.

Standard

UA generally aligns with the National Institute of Standards and Technology (NIST) standards, including NIST SP 800-63 (Digital Identity Guidelines or Guidelines). These Guidelines specify levels of assurance related to identity proofing, authentication, and federation and assertions.

User Authentication Levels

A description of UA levels of assurance, mapped to their NIST counterpart, are in the table below:

UA levels of assurance, mapped to their NIST counterparts

UA NIST
Level 1 AAL 1
Level 1 provides some assurance that the person trying to log in has control over the device or method used to access their account. It requires either one-step or multi-step login methods using various technologies. To log in successfully, the person must show they have and control the device or method used to access their account, through a secure process.
Level 2   AAL 2
Level 2 provides high confidence that the person trying to log in has control over the device or method used to access their account. Proof that the user has the device or method used to access the account, as well as control of two different authentication factors is required through secure authentication protocol(s). Approved encryption techniques are required at AAL2 and higher.
Level 3 AAL 3
Level 3 provides very high confidence that the person logging in has control over the device or method used to access their account. Logging in at AAL3 requires proof of possession of an encryption key. It requires a hardware device and a device that resists impersonation, which can be the same device. To log in at AAL3, the user must show they have and control two different login methods using secure authentication protocols. Approved encryption techniques are required.

 

In general, Levels 1-3 are applied to systems based on the following risk levels: 

System Risk Level

UA Assurance Level

Examples

Low

Level 1

Public, Student Workstations

Moderate

Level 2

Employee Workstation

High

Level 3

Systems containing sensitive or regulated data

 

Authenticator Types

Application owners and data custodians are required to enforce multi-factor authentication (MFA) for all moderate- and high-risk applications whenever possible.  MFA is encouraged (but not required) for low-risk applications.

The following factors are currently allowed at UA: 

Factor

Level 1

Level 2

Level 3

One-time passcodes (TOTP)

✓

EOL December 2025

EOL June 2025

Application-based push (via Duo or Entra MFA)

✓

✓

✓

Security Key

✓

✓

✓

Phone Call

EOL December 2025

EOL December 2025

Not allowed

SMS

EOL June 2025

Not allowed

Not allowed

 

Phone call and one-time passcodes will be disallowed for UA Assurance Level 3 effective June 2025, and disallowed for UA Assurance Level 2 effective December 2025. SMS is not a permissible authentication factor regardless of assurance level. SMS will be disallowed for UA Assurance Level 1 in June 2025.

Memorized secrets (passwords or passphrases) are a permissible authenticator type if in compliance with the complexity, storage, and usage requirements outlined in the “Password Requirements” section of this document.

Reauthentication, Timeouts, and Session Locking

Reauthentication refers to the process and frequency of periodically verifying a user’s identity after the initial authentication event.  In this context, reauthentication shall terminate a user’s session in an application or service.  

1. Re-authentication and Session Timeout

In all cases, session timeout followed by re-authentication is required when a system or service restarts.  Re-authentication (session timeout) is required for all user sessions at intervals which are appropriate for the risk level, regardless of user activity. The session should be terminated (i.e., logged out) when this interval has been reached.

2. Session Locking

User sessions for applications and services shall be locked in accordance with UA’s Minimum Security Standards. Reauthentication of users where the session timeout has not yet been reached but the inactivity period has been reached (e.g. session lock or “screen lock”) allows for only a single factor to be presented to re-enable the session.  The session lock shall obscure any sensitive or restricted data pursuant to UA’s Data Classification Standard. 

Password Requirements

The following are minimum requirements for all UA systems, services, and applications, subject to the system, service, or application supporting these requirements:

Account Type

Minimum Length

Maximum Lifetime

Standard UA User Account

16

730 Days

Privileged Account (Admin)

24

730 Days

Service Account

32

When integrity in doubt

Guest Accounts

32

60 Days

 

If a system, service, or application does not support these minimum password requirements, an exception must be obtained from ISA. Please see “Violations and Exceptions” to request an exception. 

In all cases where UA suspects that the password may have been compromised, passwords shall be immediately expired and required to be reset. 

Passwords may contain:

    • Upper and lower case letters
    • Numbers
    • Special characters, including spaces

Passwords must not contain:

    • More than four repeating or sequential characters (e.g. 11111, abcde, etc.)
    • Any part of the user’s name or assigned UA username
Authentication Requirements

1. Allow Show Password While Typing  

Applications should hide the password being entered (typically by displaying “*” in place of entered characters). Wherever possible, applications should allow the user to toggle between hashed and plain-text password entry to aid them in verifying correct entry of passwords. 

2. Allow Paste-In / Copy-Paste

Applications should allow the user to copy/paste passwords into password entry textboxes/fields to allow for the use of password manager tools. 

3. Disallow Password Hints

Wherever possible, knowledge-based password recovery should be avoided in favor of recovery via previously verified second factors (e.g. email address, phone number, etc.). 

4. Limit Attempts / Lockout Period

The ability to authenticate an account should be temporarily disabled if there are too many authentication attempts in a defined time period.  At minimum, accounts should be locked out or limited (throttled) in authentication attempts after 10 failed attempts in 10 minutes.  The lockout period should be not less than 10 minutes, and is recommended to be not greater than 30 minutes.  This requirement does not apply to privileged access accounts with system-generated passwords more than 20 characters in length or non-system generated passwords where MFA is also required.  

5. Disallow Detailed Errors

Detailed information on authentication failures should not be displayed.  Instead, authentication failures whether due to an invalid username or bad password shall display the same failure message.  It is recommended that the failure message state something similar to the following: “Unknown username or incorrect password supplied.” 

6. Utilize Risk Ratings / User Risk Monitoring

 Wherever supported, user-based risk ratings should be considered that may require earlier session timeout or reauthentication, additional MFA prompts, etc.  If risk-based authentication is utilized, ISA and the unit CIO should be informed. 

Password Hygiene

1. Sharing

Sharing of UA user account passwords is prohibited.  

Users must not provide their  password at any time and in any manner other than when accessing UA resources via an authentic login mechanism.

2. Creating a Secure Password

The most secure passwords are long and memorable. When selecting a UA user account password, users should:

    • Use a passphrase instead
    • Utilize a  list of unrelated words that are memorable to you

3. Reuse

Reuse of passwords is strongly discouraged.  Users should consider the use of a password manager to store and generate unique passwords for each separate and unique authentication need.

UA user account passwords should be:

    • Unique from passwords of other UA accounts
    • Different from personal account passwords
    • Not reused from previous passwords

4. Local Device Storage

Except when using approved password management tools, local storage of passwords is strongly discouraged on any electronic device – this includes in-browser storage of passwords (e.g. “Remember Me” functionality if passwords are stored in addition to usernames).  

5. ​Paper-Based Storage

UA strongly discourages written passwords for other than a temporary (generally defined in minutes) timeframe.  

If such a need arises:

    • Maintain control of the written password at all times.
    • Do not record the password alongside any identifying information (e.g., username, email).
    • Ensure the written password is only visible to those with a legitimate need.
    • Securely destroy the material containing the password immediately after use.

There are legitimate use cases for long-term storage of written passwords and their identifying information exist. In these cases, paper storage is permitted subject to appropriate controls, including (but not limited to): 

    • Use of a secure storage mechanism
    • Requiring two or more authorized persons to obtain the written passwords, etc.

6. System and Service-Based Storage

Systems and services storing passwords must:

    • Use strong, industry-standard encryption
    • Avoid storing passwords with reversible encryption
    • Implement salting or equivalent measures whenever possible
    • Be regularly audited and monitored for unauthorized access or potential data breaches

7. Approved Electronic Storage

Approval for password management tools will be given by the University CIO, UA CITO, or UA CISO.  Approved password/secret management tools are listed in the UA Software Catalog. Exceptions to approved password management tools will be considered pursuant to UA’s Information Security Controls Exception Handling Process. 

Violations and Exceptions

Per Board of Regents Policy & Regulation R02.07.060  violations of this Standard: 

  • may result in a reduction or loss of access privileges, or the imposition of other restrictions or conditions on access privileges;
  • may subject employees to disciplinary action, up to and including termination; 
  • may subject students to disciplinary action including expulsion according to the Student Code of Conduct procedures; and 
  • may also subject violators to criminal prosecution. 

Requesting an Exception

The process for requesting exceptions to this or other IT Security Standard are outlined in the Information Security Controls Standard.

 

Implementation

OIT Information Security and Assurance is responsible for the implementation, maintenance and interpretation of this IT Standard.

Related Standards

Information Security Controls Standard

References

This standard is intended to align with the National Institute of Standards and Technology (NIST) Special Publication 800-63b and designed to  meet the requirements of NIST 800-171 3.1.10 (Use Session Lock) and 3.1.11 (Terminate User Sessions). 

This standard is supported by University of Alaska Board of Regents Policy and Regulation Chapter 02.07.

Lifecycle and Contacts

Standard Owner: OIT Information Security and Assurance

Standard Contact: Chief Information Security Officer

Phone: 907-474-5347

Email: ua-ciso@alaska.edu

Approved: September 2024

Effective: January 2025

Next Review: September 2026