With this project, we are primarily discussing Authentication of Identity. The primary means of verification is through the use of identifiers and shared secrets. A password is really the primary shared secret. So we are really asking for a secondary form of shared secret in case the primary is forgotten and needs to be re-established, or some other identifier.
Two forms fo secondary authentication tokens.
- A unique identifier already known to the system and attached to the users identity profile.
- APU ID Number
- Social Security Number
- Phone number or street address (weak)
- A shared secret established for the purpose of establishing identity.
- A fixed question, such as your mother's maiden name (overused)
- A question and answer pair (like our current challenge question)
- A set of fixed questions, user supplies answers
- Examples
- Examples
It was decided in the first AWG meeting on this topic, that the scope would not include a review of the existing password strength policy. It should be noted, however, that the development of a new shared secret (#2 above) for the purpose of establishing identity, is in essence, no different than a password. To compromise one is to compromise both.
Mitigating Risk
Identifiers
Different identifiers have different levels of inherant risk.
A social security number has quickly become the primary unique identifier for most of the worlds criminal and financial databases. It is the primary target for identity fraud, and is very hard to effectively change. However, as awareness of its importance increases, consumers generally know to protect it. Social Security Numbers are not stored in our LDAP directories making them less accessable to applications for authentication.
An APU ID Number is a university generated unique 9 digit number, similar to a social security number, for the purpose of identifying a person at APU. As its primary purpose is to be a replacement for social security numbers for privacy reasons. Recent government regulations such as FERPA, prevent the use or display of social security numbers in certain contexts. Because it is widely used on campus, printed out on paper on class rosters etc, id cards etc., is somewhat limited as a secure identifier. Psychologically, it is not as protected as a social security number. The ApuIdNumber attribute is stored in our LDAP directory and therefore accessable for wide use in identity and authentication systems.
There are other attributes in our LDAP directory that could be considered identifiers. Multiple phone numbers and addresses associated with a person are stored, and updated via udeupa. These are considered rather weak forms of identifiers, because they are often published in various circles and handed out at the discrimination of the person.
There is a lot of other information stored in our ERP system (IFAS), that could be used to confirm identity. Things such courses taken or previous grades recieved could theoretically be used to verify identity.
One way to mitigate risk with weaker identifiers, would be to ask for several, requiring a user to answer all or some percentage of them correct.
Shared Secrets
Shared secrets are generally established at point of account creation or password reset. They can take the form of fixed questions or free form question and answers.
Generally free form question and answer pairs, such as we currently employed with the Challenge Question & Answer system, are more difficult to automate the verification of because they are more difficult to remember and answer in exactly the same way at a string level.
Predefined questions, while easier to automate, are inherantly less secure because they preset a fixed set of variables. If an attacker knows which question is asked, they can seek out the answer in relation to the target. However, our experience is that persons who develop free form question and answer pairs choose questions and answers that are generally knowable. They will often use things that persons who know them, or can perform research, can determine. In these cases, a fixed set of better questions would be more secure.
Ways to mitigate risk with predefined questions is to establsh several, and then present them to the user randomly. This way the attacker doesn't know which one will be asked. With several questions some level of verification failure needs to be established. More questions means that it is less likely a user will remember every answer. With more questions however, and some level of allowed failure increases the chance of automation succeeding as the user is given a few chances with different questions.
General Considerations
Brute Force Precautions
- A time pause betweeen retries should be established to prevent or at least frustrate direct crack attempts.
- A lock out should occur if too many attempts fail.
User Notification
It is generally good practice to notify the user that their password has been reset. There is some question about how to notify them, because if their account is compromised such electronic messages would be intercepted. The exception is those with email that forwards to another account, or physical mail.
Auditing
Security should not just be evaluated in terms of preventing breaches, but also in how quickly and intelligently you can respond to incidents. This requires good logging and auditing mechanisms. Whatever solution is developed should log this type of password reset, differently than a normal user or administrative password change. It should include a separate time stamp for this catagory of resets as well. Since the reset will be browser based, the client IP address or other such information would be easy to implement and increase investigative capabilities.
Fall Back
It should be noted, that even though the goal of this process improvement, is to allow for self-service password resets, it is impossible to provide a system that would work 100% of the time for 100% of our users. There will be those, because of technical or other constraints who will still need to contact the support desk. Reasons besides technical scenarios, such as not having access to the internet or an already authenticated workstation, are listed below.
If a user so chooses, he or she should be able to opt out of the password reset option. Challenge questions in particular could infringe on privacy or security desires of users. If they so choose, they should be able to fall back to contacting the support desk, and providing physical or faxed ID.
Certain high level University Administrators, Staff or Faculty, whose accounts pose a greater risk if compromised, could if so desired by policy, be excluded from the password reset mechanism. The same technical mechanism created for the opt out solution previously stated, could be used to handle this feature.
