Password Information for System Administrators
Below is information for supporting user accounts and design/implementation of systems/applications.
Provisioning and Support of User Accounts
The following are several recommendations for individuals who are responsible for provisioning and support of user accounts. See the Account Management, Application Access Control, Operating System Access Control and Authentication Standards in the University's Information Security policy for specific requirements that you must follow.
Enforce Strong Passwords/Passphrases
Many systems and applications include functionality that prevents a user from setting a password/passphrase that does not meet certain criteria. Functionality such as this should be leveraged to ensure only strong passwords/passphrases are being set. See Account Management for more information on password/passphrase complexity.
Require Periodic Password/Passphrase Changes
Forcing a periodic password/passphrase change serves as a reminder to users and eliminates the human factor in determining whether to change a password. A general rule of thumb is to force a password change every 90 to 365 days.
Require a Change of Initial or “First-Time” Passwords/Passphrases
Forcing a user to change their initial password/passphrase helps ensure that only that user knows their password/passphrase. Depending on what process is being used to create and distribute the password/passphrase to the user, this practice can also help mitigate the risk of the initial password/passphrase being guessed or intercepted during transmission to the user. This guidance also applies to situations where a password/passphrase must be manually reset.
Force Expiration of Initial or “First-Time” Passwords/Passphrases
In certain situations, a user may be issued a new account and not access that account for a period of time. Initial passwords/passphrases have a higher risk of being guessed or intercepted depending on what process is being used to create and distribute passwords/passphrases. Forcing an initial password/passphrase to expire after a period of time (e.g. 72 hours) helps mitigate this risk.
Do Not Use Restricted Information for Initial or “First-Time” Passwords/Passphrases
Restricted information includes, but is not limited to, social security number, name, date of birth, etc. This type of data should not be used wholly or in part to formulate an initial password/passphrase.
Always Verify a User’s Identity Before Resetting a Password/Passphrase
A user’s identity should always be validated prior to resetting a password/passphrase. If the request is in-person, photo identification (e.g. UCard, valid state ID, or current passport) is a sufficient means of doing this. If the request is by phone, validating an identity is much more difficult. One method of doing this is to have the user fax in a copy of their photo id in addition to having the helpline ask the user some questions. Another option is to have the person’s manager call and confirm the requests.
Never Ask for a User’s Password/Passphrase
As stated above, individual user account passwords/passphrases should not be shared. A natural corollary to this guidance is to never ask others for their passwords/passphrases. Delegation of permission is one alternative to asking a user for their password/passphrase. Some applications include functionality that allows an administrator to impersonate another user, without entering that user’s password/passphrase, while still tying actions back to the administrator’s user account. This is also an acceptable alternative.
Configuration, Design, and Implementation of Systems and Applications
The following are several additional recommendations for individuals who are responsible for the configuration, design, and implementation of systems and applications.
Change Default Account Passwords/Passphrases
Default accounts are often the source of unauthorized access by a malicious user. When possible, they should be disabled completely. If the account cannot be disabled, the default passwords/passphrases should be changed immediately upon installation and configuration of the system or application.
Implement Strict Controls for System-Level and Shared Service Account Passwords/Passphrases
Shared service accounts typically provide an elevated level of access to a system. System-level accounts, such as root and Administrator, provide complete control over a system. This makes these types of accounts highly susceptible to malicious activity. As a result, a more lengthy and complex password/passphrase should be implemented. System-level and shared service accounts are typically critical to the operation of a system or application. Because of this, these passwords/passphrases are often known by more than one administrator. Passwords/passphrases should be changed anytime someone with knowledge of the password/passphrase changes job responsibilities or terminates employment. Use of accounts such as root and Administrator should be limited as much as possible. Alternatives should be explored such as using sudo in place of root, creating unique accounts for Windows administration instead of using default accounts or in Windows using the "Run As" administrator command.
Avoid Using the Same Password/Passphrase for Multiple Administrator Accounts
Using the same password/passphrase for multiple accounts can simplify administration of systems and applications. However, this practice can also have a chain effect allowing an attacker to break into multiple systems as a result of compromising a single account password/passphrase. It is recommended that different passwords/passphrases be used for test and production systems.
Do Not Allow Passwords/Passphrases to be Transmitted in Plain-Text
Passwords/Passphrases transmitted in plain-text can be easily intercepted by someone with malicious intent. Protocols such as FTP, HTTP, SMTP and Telnet all natively transmit data (including your password/passphrase) in plain-text. Secure alternatives include transmitting passwords via an encrypted tunnel (e.g. IPSec, SSH, TLS), using a one-way hash or implementing a ticket based authentication scheme such as Kerberos.
Do Not Store Passwords/Passphrases in Easily Reversible Form
Passwords/Passphrases should not be stored or transmitted using weak encryption or hashing algorithms. For example, the DES encryption algorithm and the MD-4 hash algorithm both have known security weaknesses that could allow protected data to be deciphered. Encryption algorithms such as 3DES or AES and hashing algorithms such as SHA-256 are stronger alternatives to the previously mentioned algorithms. Also Windows passwords/passphrases should not be stored using the vulnerable LANMAN hash.
Set Passwords/Passphrases on all devices and software supporting authentication
Passwords/passphrases should be set unless using a higher level of authentication (e.g. Duo). Passwords whether at the hardware, operating system, application or database level offer another layer of security defense.
Implement Automated Notification of a Password/Passphrase Change or Reset
When a password/passphrase is changed or reset, an e-mail should be automatically sent to the owner of a user account whenever possible. This provides a user with confirmation that the change or reset was successful and also alerts a user if a password is unknowingly changed or reset.
Delete Old Accounts
Delete accounts that are no longer used. Old accounts are used by hackers to gain access to systems.
Basic Password/Passphrase Configuration Settings
See the Account Management, Application Access Control, Operating System Access Control and Authentication Standards in the University's Information Security policy for specific requirements that you must follow.
- Information Security policy
- Enterprise Access Requests (including how to report terminations, department transfers and leave of absences)
- Duo (Two-factor authentication)
- Choose Strong Passwords and Keep Them Safe
- U of M Shibboleth Authentication
University of Minnesota has permission from Carnegie Mellon University to use their content on this website.