20090326 - Sponsor Summary March 26, 2009

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

Attendees:

• Joyce Landreth
• Daniel Fisher
• Karen Herrington
• Dean Kirstein
• Brad Tilley
• Ken McCrery
• Rhonda Randel
• Kevin Rooney
• Marc DeBonis
• Mary Dunker 

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

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; quizical face indicates item discussed but decision still needed

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 student 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. PID of 4Help person. Need to know who changed someone's password and when. (IMS can tell that now from new DAT.)
4. For each credential (PID, Hokies), we should evaluate options for reset criteria and also cost/benefit of that option. (???) Ignore this for now.
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.
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.
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 24 hours to change that password. When they change it, if they have not already generated Q/A pairs, they should be required to select/create challenge questions/responses.  Hokies pwd that is changed by administrator is forced to be changed at next login. If administrators are funnelled through the same interface, forcing Q/A pair creation can be done for Hokies, too. (Not sure if there was enough discussion on funnelling all Hokies pwd resets through the new reset interface.)
   • During PIDGen
   • When a person changes his/her password (might not force this initially, but could do so eventually). Sponsors say "force". Brad pointed out security concerns with this approach. Sponsors may wish to reconsider.
   • Anytime, if authenticating to PWD reset service with an eToken. Should a person be allowed to create Q/A pairs if they passess an eToken? (See item number 9.)
   • If you have an eToken and use it to reset PID/Hokies pwd, do not force a person to create pairs that do not alreay exist. Allow them to reset PID/Hokies pwd without using pairs.
   • (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. Interface/tool to create Q/A pairs should be different from reset tool.
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.
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.
11. Consider implications of renaming a PID.
12. If possible, use/reuse the existing web service (modified) that is employed by PIDGen, as the basis for the new password reset service.
13. Recommended entry points for creating Q/A pairs: During initial creation of PID and/or Hokies ID. Also, see #6 above.
14. 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.
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.
16. Include a CAPTCHA on the page a person uses to create their Q/A pairs.
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?
   
   

SETI Test and Deployment team offers to perform a usability study