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

Invitees/attendees (* indicates unable to attend):

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

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

Scope: PID and Hokies passwords

Each meeting agenda should include a review of wiki comments on the notes from the previous meeting.

Items to consider for requirements - Thumbs-up indicates Sponsors agree; thumbs down indicates sponsors agree tha answer is "no"; quizical face indicates item discussed but decision still needed; question mark indicates item not well defined or not understood.

  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. (thumbs up)
  2. Users should be trained/encouraged/forced? to use the self-service tool rather than calling 4Help. (Use student Orientation as opportunity to train.) (thumbs up)
  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. PID of 4Help person. Need to know who changed someone's password and when. (IMS can tell that now from new DAT.) (thumbs up)
  4. For each credential (PID, Hokies), we should evaluate options for reset criteria and also cost/benefit of that option. (???) Ignore this for now. (thumbs down)
  5. Monitoring for attacks & failed login attempts should be done. CNS sends an e-mail to the guest owner after 4 failed answer attempts. Need to decide x number of attempts within Y timeframe. What should be done if/when that happens? Lock out of tool? Lock out of access to the tool by IP address? Sending e-mail to the owner would alert them that someone is trying to access their q/A pairs. Sponsors need to decide if the e-mail is something they want to be sent. (wink)
  6. Log/record information to indicate how a password was reset; i.e., Q/A pair, 4Help, eToken authentication. Information is needed; developers can decide how to implement. A central interface would be nice, but is not required for IMS. (thumbs up)
  7. Suggestions for opportunities to force a person to create Q/A pair:
  8. Interface/tool to create Q/A pairs should be different from reset tool. (thumbs up)
  9. Brad suggests we need to ask for more information than PID/pwd or Hokies/pwd in order to create pairs. Might want to reconsider "general" interface that allows user to create pairs. Suggestion was made to only allow Q/A creation if a person is a) generating his/her PID or b) changing his/her password in response to 4help resetting the password to a temporary one that expires in 24 hours. (wink)
  10. 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. Decision has been made to re-scope the project, and only provide the new self-service reset tool for PIDs.
  11. Consider implications of renaming a PID. (question)
  12. If possible, use/reuse the existing web service (modified) that is employed by PIDGen, as the basis for the new password reset service. (thumbs up)
  13. Recommended entry points for creating Q/A pairs: During initial creation of PID and/or Hokies ID (thumbs up) . Also, see #7 above.
  14. If challenge/response 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. YES (thumbs up) . Answers would be hashed (thumbs up) . Does the help desk have a requirement to ask a question and get an answer? No requirement. No need to encrypt the question (thumbs down) .
  15. 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. Decision: Don't allow voluntary change of Q/A(thumbs down) . Should you allow them to choose same Q/A pairs as before (during re-creation after 4Help resets PWD? YES (thumbs up) .
  16. Include a CAPTCHA on the page a person uses to create their Q/A pairs. It will slow things down. No captcha on creation tool (thumbs down) . Captcha useful in tool that allows them to reset pwd?  PID must be entered first. Would CAPTCHA help here? YES (thumbs up) . In addition to a CAPTCHA, invoke limits on the number of failed attempts that are allowed during a given time period (thumbs up) . Also, impose limits on the number of times 4Help is allowed to reset a password during a given time period (thumbs up) . Include an override for IMS to use. (thumbs up)
  17. Do not allow using the same Q/A pairs for eTokens as for PID/Hokies.
  18. 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.
  19. If Q/A pairs are used, there are potentially 3 sets: 1) PID/Hokies, 2) 4Help-use only 3) eToken
  20. 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?
  9. If one-time password devices become supported by Central IT, should authenticating to the SS pwd reset tool with the OTP device allow a person to change his/her PID or Hokies password?
  10. Should OTP authentication to the Q/A pair creation tool allow a person to create Q/A pairs without answering PIDgen questions? 

SETI Test and Deployment team offers to perform a usability study

4Help's Password Reset Procedures

Links to Other Resources for Self-Service Password Tools