20090313 - Self-Service PWD Summary March 13, 2009

Self-service password reset project summary for sponsors (IMS and 4Help) 

The purpose of this document is to assist the sponsors of the Self-service password reset project in determining the following for the project.

• constraints
• assumptions
• policies
• risks
• issues that need to be addressed regarding usability vs. security

Definition: Password reset means changing a password without knowing the old password.

Scope: PID and Hokies passwords

Items to consider for requirements

1. Any self-service reset tool must be at least as secure as the current method of calling 4Help or IMS to reset the password.
2. Users should be trained/encouraged/forced? to use the self-service tool rather than calling 4Help. (Use Orientation as opportunity to train.)
3. Retain option open for calling 4Help to either reset or assist in resetting passwords. We should record the credential that was used to authenticate to the tool to reset the password.
4. For each credential (PID, Hokies), we should evaluate options for reset criteria and also cost/benefit of that option. (???)
5. Monitoring for attacks & failed login attempts should be done. CNS sends an e-mail to the guest owner after 4 failed login attempts.
6. Log/record information to indicate how a password was reset; i.e., Q/A pair, 4Help, eToken authentication.
7. Suggestions for opportunities to force a person to create Q/A pair:
   • When a person calls 4Help to reset their password, the person has 48 hours to change that password. When they change it, if they have not already generated Q/A pairs, they should be required to selct/create challenge questions/responses.
   • During PIDGen
   • When a person changes his/her passwowrd (might not force this initially, but could do so eventually)
   • Anytime, if authenticating to PWD reset service with an eToken
   • (Maybe) somewhere in new My VT
   • During PID reprovisioning/renewal process, if such a process were to exist in the future.
   • During CAS authentication
   • While entering leave (For employees)
   • Using Hokie SPA
8. Hokies OU Admins can currently reset Hokies passwords for their users. If we want to encourage/force self-service, all the other mechanisms that exist for passwords being reset need to be considered.
9. Consider implications of renaming a PID.
10. If possible, use/reuse the existing web service (modified) that is employed by PIDGen, as the basis for the new password reset service.
11. Recommended entry points for creating Q/A pairs: During initial creation of PID and/or Hokies ID. Also, see #6 above.
12. If challenge/respons questions are used, and if there is only one set of questions, for both Hokies and PID, store the questions/answers in the ED Registry. ED Schema has already been set up to accommodate Q/A pairs.
13. If challenge/response questions are used, require that they be answered correctly in order for a person to change or select a new question/answer.
14. Include a CAPTCHA on the page a person uses to create their Q/A pairs.
15. Do not allow using the same Q/A pairs for eTokens as for PID/Hokies.
16. Include a separate secret question that can only be used by 4Help or IMS to reset the password for the user. Might not need to hash this answer.
17. If Q/A paris are used, there are potentially 3 sets: 1) PID/Hokies, 2) 4Help-use only 3) eToken
18. When a password is reset, notify the user with e-mail or voice mail.

 Questions for Sponsors

1.  Should a person be allowed to use one set of electronic credentials to reset the password for another digitial identity? Recommendation: Authenticating to the password reset tool with the eToken should allow password reset for Hokies and PID without answer questions, since the eToken carries a higher level of assurance in the identity of the authenticated user than does the PID or Hokies ID. Authenticating with PID should not allow resetting Hokies without answering the questions, nor vice versa. In general, we could use a credential with a higher LOA to reset the password of a credential with a lower LOA.
2. Should there be a single interface for resetting PID and Hokies password?
3. Should challenge/response questions be used? Recommendation: Yes
   If answer to #3 is yes, then
   1. Who should be able to view the questions and/or responses? 4Help? IMS? Only the user?
   2. Should the questions/responses be encrypted? CNS allows NOC to view questions. CNS guest password reset requires that that user know which questions are his/hers, from a list that pops up. Recommendation: Answers should be on-way hashed.
   3. Should the questions be pre-defined or user-generated or a combination? (SETI Test offers to perform a usability study w/ITSO to determine balance between usability and security.) Brian Early, CNS recommends not allowing users to create their own questions.
   4. What process(es) should be used to create the questions?
   5. How many questions must a user answer? COLA application requires 2 questions be answered correctly.
   6. Where should the questions be stored? Recommendation: Store in Enterprise Directory registry, which already has a table for them.
   7. Should there be a different set of questions for Hokies vs. PID? Recommendation (Mary's interpretation): No - use same set for PID and Hokies, since these credentials are at same LOA and since we do not reommend allowing PID authentication to allow resetting Hokies password and vice versa..
   8. Should we request another piece of information (VT ID#?) in addition to answering challenge questions? Recommendation: Yes. IMS is investigating whether any additional information from Banner would be useful/appropriate. The answers to the initial questions used to generate a PID are less well-known at PIDGen time than later in the student or employee's life cycle at Virginia Tech.
4. Should other online reset methods be explored, such as graphical recognition, typing recognition, biometrics, site keys, one-time password sent via e-mail?
5. Should 4Help and IRM use the same Web interface as the user to change the passwords?
6. Shoud there also be an automated mechanism where a random password is sent to the user in e-mail, and the user would go to a link to reset their password using this random password to login initiatlly. Recommendation: no
7. Is it possible to obtain unauthenticated network access to a page that allows the user to reset the password? (This is a technical question to ask CNS.)
8. Should we incorporate a means to prevent the PID password from being the same as the Hokies password? (May not be able to enforce this except during initial setting.) If the passwords are required to be different, should we try to prevent a user from discovering what one password is during creation of  the other password?