Password and Authentication Standard
Overview
Promoting secure access to 绿奴天花板 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 绿奴天花板 for various accounts, including user, system, service, and email accounts, as well as for accessing specialized applications.
Scope
Information Security and Assurance (ISA) Standards are mandatory and apply to the 绿奴天花板 System and all users of 绿奴天花板 computing resources. This standard supplements and supports Board of Regents Policy & Regulation R02.07. These standards are reviewed and approved by the CIO Management Team (CMT), a system-wide governance group consisting of each university CIO, the System CITO, and the System CISO. Business units maintaining their own security standards should utilize this standard as a baseline and may add additional requirements or detail as appropriate for their business needs, however, may not weaken any individual element of this standard without an approved Information Security Controls Exception.
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 绿奴天花板 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 绿奴天花板 networks;
- Any third-party providers in a contractual relationship with the university that maintains sensitive 绿奴天花板 data.
This standard is periodically reviewed and updated to respond to emerging threats, changes in legal and regulatory requirements, and technological advances.
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鈥檙e 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
绿奴天花板 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 绿奴天花板 levels of assurance, mapped to their NIST counterpart, are in the table below:
绿奴天花板 levels of assurance, mapped to their NIST counterparts
绿奴天花板 | 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 |
绿奴天花板 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 绿奴天花板:
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 绿奴天花板 Assurance Level 3 effective June 2025, and disallowed for 绿奴天花板 Assurance Level 2 effective December 2025. SMS is not a permissible authentication factor regardless of assurance level. SMS will be disallowed for 绿奴天花板 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 鈥淧assword Requirements鈥 section of this document.
Reauthentication, Timeouts, and Session Locking
Reauthentication refers to the process and frequency of periodically verifying a user鈥檚 identity after the initial authentication event. In this context, reauthentication shall terminate a user鈥檚 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 绿奴天花板鈥檚 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 鈥渟creen 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 绿奴天花板鈥檚 Data Classification Standard.
Password Requirements
The following are minimum requirements for all 绿奴天花板 systems, services, and applications, subject to the system, service, or application supporting these requirements:
Account Type |
Minimum Length |
Maximum Lifetime |
Standard 绿奴天花板 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 鈥淰iolations and Exceptions鈥 to request an exception.
In all cases where 绿奴天花板 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鈥檚 name or assigned 绿奴天花板 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: 鈥淯nknown 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 绿奴天花板 user account passwords is prohibited.
Users must not provide their password at any time and in any manner other than when accessing 绿奴天花板 resources via an authentic login mechanism.
2. Creating a Secure Password
The most secure passwords are long and memorable. When selecting a 绿奴天花板 user account password, users should:
-
- Use a 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.
绿奴天花板 user account passwords should be:
-
- Unique from passwords of other 绿奴天花板 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. 鈥淩emember Me鈥 functionality if passwords are stored in addition to usernames).
5. 鈥婸aper-Based Storage
绿奴天花板 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, 绿奴天花板 CITO, or 绿奴天花板 CISO. Approved password/secret management tools are listed in the . Exceptions to approved password management tools will be considered pursuant to 绿奴天花板鈥檚 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 and designed to meet the requirements of 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