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:
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.
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:
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 www.passwordstrengthcalculator.com 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.
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.
Review the following strong and weak password characteristics and then change your NetID password and other campus passwords that do not meet the standards.
The criteria for the UW-Madison Baseline Password Standard are:
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.
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 firstname.lastname@example.org.
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.
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.
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.
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.
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:
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.
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.