Credentials - Technical IT Staff

info Review the content by navigating between the tabs below.

Topic Information

What are Credentials?

A credential is used to verify a person's identity and ability to access something. A driver's license, birth certificate, or a passport are examples of paper credentials for citizenship. A computer system uses different credentials to identify the user. A computer system often has a username and one of three authentication methods:

  • something you know, such as a password
  • something you have, such as certificate, computer, or email address
  • something you are, such as your fingerprint

There is often a subjective factor with paper credentials. For example, if you present an identification that has someone else's picture, it may not work. A computer system does not have subjectivity. For example, if a fraudulent user enters the correct username and password the computer will accept the credentials.

Why would attackers want your NetID and password?

The answer to this depends on your access to systems on campus. Your credentials could be used to create fraudulent transactions, access sensitive systems, or to trick other users into providing their credentials. Some examples could include:

  • Access to MyUW, Human Resource System, or the campus accounting system.
  • To use UW Email to distribute spam with a email address.
  • Possibly to submit fraudulent transactions or documents.

How do attackers get your credentials?

There are various technical and non-technical means that can be used to obtain your credentials. A non-technical means include social engineering attacks where the attacker request your credentials via email, telephone, or a link requesting you log into a website.

The technical means are not much more sophisticated. There are computer programs that will guess commonly used passwords or dictionary words in a matter of minutes. A list of the most common passwords can be found here.

"Heartbleed" was a vulnerability where attackers potentially gained access to your NetID credentials. The lesson learned from this is to make sure you change your password frequently and whenever you are informed of these types of attacks.

In addition, there are computer programs that will guess every possible password combination. The time it takes the program depends on the length and complexity of your password. Below is an example:

Password Length Upper and Lower Case Letters Upper and Lower Case Letters with Numbers Upper and Lower Case Letters, Numbers, and Special Characters
8 11 seconds 44 seconds 20 minutes
12 2 years 20 years 3,018 years
16 18,000,000 years 302,000,000 years
Note: For this exercise we used which only provides an estimate for the password useful life. There are many variables such as attack speed, lockout timers, forced password changes, etc.

Finally, cyber criminals often perform reconnaissance on a target to obtain information to conduct an attack. The University has a lot of publically accessible information including organizational charts, directories, position descriptions, and many more items. In addition, a lot of information can be obtained about an organization through Google searches and social media sites (Facebook, Twitter, Instagram, and many more.) This information can provide an attacker half the information needed (i.e. username) or potential passwords.

How to secure your credentials?

Some best practices for securing your password can be found in the Password Standard for UW-Madison. Remember, do not use passwords that include common names, dictionary words, or that follow common keyboard patterns (e.g. 123456, qwerty, asdfg). Never share your password with anybody or write the password down unless you can secure the paper document. Finally, password should include lower and upper case letters, numbers, and special characters.

It is your responsibility to ensure your NetID/password and other credentials are managed securely - Don’t be the weak link in this system.

Creating Strong Passwords

Review the following strong and weak password characteristics and then change your NetID password and other campus passwords that do not meet the standards.

Strong Password Characteristics

The criteria for the UW-Madison Baseline Password Standard are:

  • At least eight alphanumeric characters long
  • Contain at least three of the following four categories:
    • Upper case characters (e.g., A-Z)
    • Lower case characters (e.g., a-z)
    • Digits (e.g., 0-9)
    • Special characters ( e.g., !@#$%^&*)
  • Do not contain a common proper name, login ID, email address, initials, first, middle or last name

Characteristics of a Weak Password

  • Contain less than twelve characters
  • Can be found in a dictionary (English or foreign) or a word in any language, slang, dialect, jargon, etc.
  • Is the same as your user name or login name
  • Is a common usage word such as names of family, pets, friends, computer terms, birthdays or other personal information, or number patterns like aaabbb, dddddd, qwerty, 123456, etc.
  • Any of the above preceded or followed by a digit (e.g., secret1, 1secret)

Password Management Best Practices - Technical Content

  1. Change your passwords at least twice a year. The reason we suggest changing your password this frequently is to protect against the threat of dictionary attacks.
  2. Avoid re-using or duplicating passwords between work and personal accounts (e.g. your online banking account or Facebook).
  3. Never provide your username and password to anyone else. No one should ask for your NetID and password, not even other staff. This includes via email, over the phone or in person. Similarly, do not ask anyone else for his or her NetID and password.
  4. Do not use your NetID/password for systems that do not officially support NetIDs. Personal related uses would include subscriptions, on-line banking, etc. Work related uses would include database accounts, file server accounts, etc. Your NetID/password should be used ONLY for authenticating to the systems for which that pair was designed.
  5. If you are responsible for managing many credentials, we recommend using a password manager. However, ensure that you are using an exceptionally strong password to protect the rest and periodically change that password. Password managers you may choose to use:
  6. Use unique credentials when developing code or setting up new systems.
  7. Do not use the vendor-supplied default password for any system. Change it immediately to a new, strong password. This includes test environments. UW-Madison has suffered several compromised systems due to weak passwords that were "supposed to be temporary".

Managing Passwords - Technical Content

With an ever-increasing number of credentials to manage, password management becomes an ever more important consideration. If your department does not have its own policy language on this topic, please consider referencing DoIT’s. The following are best practices for password management as well as specific recommendations for various types of accounts, taken from the Standards for Managing Programmatic Accounts at DoIT.

System credentials are those used within any environment - beta, test, quality assurance, and/or production, on various computers and workstations that provide direct access to databases, applications or the operating system itself.

As technical staff, you maintain a growing list of credentials. You also understand that all passwords must follow the password standard. You are entrusted with credentials that are the keys to systems and others' confidential information. The security controls on these systems can be severely weakened by poor credentials or credential management, which increase risk to the UW population.

  • Devices and systems connected to the University of Wisconsin-Madison network must require passwords to meet the minimum standards and, whenever possible, technically enforce them.
  • Faculty, staff and students must adhere to the Minimum Passwords Standards for all systems and applications that come into contact with University resources.
  • You should use a password manager to safely manage your credentials.

The use of shared password managers means sharing passwords among select administrators, but this is the lesser of two evils. Ideally your team will maintain separate password managers per projects/systems/applications and not share ALL credentials with everyone. Least privilege is the security practice to adhere to.

If your technical team would like Security Team members to attend a group meeting to assist with password managers, contact us at

Managing "Test" and "Service" Account Passwords (A Subset of System Accounts) - Technical Content

Test and service accounts are system credentials as defined above but used specifically for testing purposes and as application-to-application credentials.

If your department does not have its own policy language on this topic, please consider referencing DoIT’s. The DoIT standard for Test and Service accounts provides guidelines for logging and monitoring and criteria managing both test and service (a.k.a. entity-to-entity) accounts.

  1. Logging and monitoring
  2. Logging helps detect possible security problems and investigate the scope of a suspected incident. Developers should take the initiative to check on what logging and monitoring is available and what portion of the logging (if any) must be done by the application to augment the OS logs.
    • Make sure each login, login attempt, and authorization decision is logged.
    • Make sure security configuration changes are logged.
    • Make sure that logging required by regulations or contracts is done.
    • Make sure the logs are available for monitoring.
  3. Test accounts
  4. A person using a test account enters a password to authenticate for each use. Some accounts are only used by a single person for a limited period of time. Others accounts are used to simulate particular functions, and as a result must be shared by a team. Sharing accounts makes it more difficult to assure that only the authorized users are using them. Due to the unique features of the systems and the complexity of integrating them, the techniques for managing such shared test accounts will vary considerably among teams.
    • Follow the logging and monitoring standards (1.x above), and all applicable policies.
    • Don't use personal accounts as test accounts.
    • Use different test accounts for each separate environment, (e.g., test, dev, QA, production, etc.).
    • When possible, only authorize access by one specific known individual at a time.
    • Only authorize access for a limited period of time.
    • Change the password when a user of an account changes.
    • Change passwords on a regular basis.
  5. Entity-to-entity accounts
  6. Entity-to-entity accounts are used by systems and applications (i.e. entities) where a person does NOT usually enter a password for each use. The password needs to stored somewhere accessible by the authenticating entity. The techniques for "hiding" the password will vary among development/operating environments. Implementation will vary among applications. There is no fool-proof solution, but the better the protection, the less likely an attacker will persevere long enough to break in.
    • Follow the logging and monitoring standards (1.x above), and all applicable policies.
    • Don't use personal accounts for entity-to-entity communications.
    • Use different entity-to-entity accounts for each environment, (e.g., test, dev, QA, production, etc.).
    • Whenever possible, use different accounts and credentials for different entities or functions that are accessing the same resource.
    • Be as specific as possible in restricting the ongoing use of an account.
    • Avoid storing the password in the source code or anywhere else in the application. Instead, get the password from the operating/development environment.
    • Store the password so it can be easily changed.
    • Store the password so it is only interpretable by an authorized entity, and only accessible when running in a certain context.

Multi-factor (Strong) Authentication

The problem with passwords is that they are quickly becoming dated. Even if you use strong passwords, with newer technologies, it is becoming easier for cyber attackers to crack the passwords or to collect credentials through social engineering or phishing. Multi-factor authentication is an enhanced way of authenticating using two out of three factors. These three factors are:

  • something you know, such as a password,
  • something you have, such as your passport, phone number or email address and
  • something you are, such as your fingerprint.

An example of one of the first multi-factor authentication used at the University of Wisconsin is the Human Resource System (HRS). When using two factor authentication, a user presents a token with a 6-digit value showing (something you have) and enters a password or phase (something you know). In addition, the application must know how to validate the token/password information in order to grant access to the restricted data. This is similar to how an ATM card works.

Expect usage of multi-factor to increase as username/password pairs become too easy to break.

Use multi-factor authentication whenever possible, especially for critical services containing or storing sensitive or restricted data. Since criminals have to work much harder to try and compromise your credentials, multi-factor authentication goes much further in protecting than a simple username and password.

New Technologies/Trends

Updating Campus Password Recommendations

At UW-Madison, the Credential Policy Team has developed new password recommendations for campus. The University has adopted forms of strong authentication for select groups of users of specific services that contain high-risk data. Many other systems—including those maintained by the Institution’s distributed IT community—also contain significant amounts of high-risk data. Widespread use of strong authentication is more and more becoming the norm outside the University. Strong authentication alone doesn’t solve all of the University’s information security challenges, but it is a vital part of a broader solution. For more details regarding this project, view the Credential Policy wiki page.