UW–Madison has adopted an IT Credentials Policy, UW-528. This policy logically fits into a framework that follows NIST SP 800-63, “Digital Identity Guidelines.” An authentication policy would also fit into this framework and may be developed in the future. However, no timeline for development of an authentication policy has been established.

MFA is more appropriately addressed in an authentication policy than a credentials policy. Specific tools used for MFA (e.g., Duo) do constitute credentials, and separate standards should be developed for these tools. A future authentication policy should address MFA and specify what authenticators are appropriate.

NIST 800-63 recommends against required password changes, as it tends to decrease password quality.¹

Common authentication and authorization systems provide the following advantages that increase overall security and improve user experience:

• Uniform security implementation and risk assessment
• Common and consistent user experience
• Efficient implementation, support and maintenance

Only when there is a use case that is not covered by the UW–Madison Password Standard. The Password Standard is based on NIST 800-63, which considers both technical and usability factors. 

Using a single standard throughout the university:

• Simplifies audit and risk review
• Improves usability and user experience by²:
  • Creating a consistent experience for all UW–Madison users, regardless of their role
  • Establishing a uniform set of requirements that improves the efficacy of security training 
  • Enabling use of institutional authentication systems.

Because having multiple standards erodes the benefits described above, the use of different (including “more stringent”) requirements is discouraged. However, if a use case is not covered by the UW–Madison Password Standard, a unit may establish a Use-Case-Specific Standard.

Requirements for adopting, developing, and documenting Use-Case-Specific Standards are available in UW-528 IT Credentials. 

Even when it should not be required, use of longer, stronger passwords can be encouraged by:

• Implementing authentication systems that support best practices for usability³
• Modeling and supporting best practices (see password composition best practices question below for more information).

A Use-Case-Specific Standard is needed when there is a technical barrier or a regulatory or contractual requirement that cannot be met by following the Password Standard.

UW-528 IT Credentials requires all Use-Case-Specific Standards to be documented. The documentation must specify a standard that works within the limitations of the use-case and must describe any required compensating controls. 

Possible examples of Use-Case-Specific Standards include but are not limited to:

• Situation: A device does not allow long passwords or allows only a single password.
  • Document in a Use-Case Standard: Processes and compensating controls, such as limiting network access to the device and controlling access to the password(s).
• Situation: A device requires use of a shared local account.
  • Document in a Use-Case Standard: Use of a gateway that implements the campus standard as a compensating access control.
• Situation: A device with no sensitive information that is deployed as a public kiosk must be accessible without a password.
  • Document in a Use-Case Standard: Exemption of the device on the basis that it contains no sensitive information.

Once established, a Use-Case-Specific Standard should be applied consistently for all similar use cases. For example, if a Use-Case-Specific Standard developed for one piece of equipment can apply to a newly acquired piece of equipment, you should use the existing standard instead of creating a new one. All Use-Case-Specific Standards must be documented, per UW-528 IT Credentials.

• If possible, change the password of the compromised account, or advise the account owner to change the password. Then contact your local IT staff or the DoIT Help Desk.
• If you are IT Staff, follow your unit’s incident response procedure or the university incident response procedure, as appropriate. (See also UW-Madison - IT - Incident Reporting and Response Procedures Flowchart.)

More information about reporting compromised credentials and other incidents is available at Reporting an incident to the Office of Cybersecurity.

Specific answers will vary from case to case. In general, though, you can:

• Require users to change their passwords the first time they use the password you provided
• Refrain from reusing passwords (and encourage users to do the same)
• Use short-lived tokens and communicate them appropriately to users
• Provide appropriate one-time authentication links instead of emailing passwords

Use this opportunity to recommend best practices that go beyond minimum requirements (see password composition best practices question below for more information).

• Model desired behaviors through your own practices. For example:
  • To encourage users to use passphrases that are both longer than the minimum and easier for users to memorize, you can provide temporary passwords in passphrase form. By using this format, you are tacitly communicating that users should use passphrases when they create their own passwords.
  • To reinforce the idea that users should not include their passwords in any email, do not use email to provide temporary passwords. Instead, use one-time secrets or time-limited authentication codes. Though less preferred, alternative verified, real-time communication channels, such as live chat or text message, can be used when needed.
    • Users may not understand the differences between temporary and regular passwords well enough to recognize that emailing a temporary, time-limited password can be lower-risk, while emailing a regular password is always high-risk.
• Provide or recommend easy-to-use services that encourage best practices, such as:
  • Passphrase generators
  • Password managers
• Educate users about best practices by providing:
  • Training
  • Resources, such as:
    • UW–Madison’s Password Best Practices
    • Tips from recognized cybersecurity sources

Alternatives will vary by system, but application keys and X509 Certificates are common credential options. Each type of credential option has its own security profile (for example, the APIs on the developer portal use OAuth2 Access Tokens). All options require that credentials be kept secure.

Keep the password secure. Follow the Password Standard and best practices for storing and sharing secrets, including using a key management service or password manager.

Create and document a Use-Case-Specific Standard that will apply to all devices in a similar situation and with a similar risk profile. Include the required compensating controls for these devices in the Use-Case-Specific Standard.

If you need to implement credentials, you should follow your customer’s policy and standard. When possible, you should use federated authentication so that you do not have to implement credentials in your application. Federated authentication also offers other advantages (see password composition best practices question above).