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

Invitees (* indicates unable to attend):

  • Joyce Landreth *
  • Greg Kroll
  • Daniel Fisher
  • Karen Herrington
  • Dean Kirstein
  • Brad Tilley
  • Ken McCrery
  • Rhonda Randel *
  • Kevin Rooney
  • Marc DeBonis * (Matt Hart represented MIG)
  • Mary Dunker 
  • Wayne Donald

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; 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:
    • 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. (thumbs up)  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.) (wink)
    • During PIDGen (thumbs up)
    • 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. (wink)
    • 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.) (wink)
    • 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. (thumbs up)
    • (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(question)
  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.
  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?
  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


  • No labels

3 Comments

  1. Mary Dunker

    Apr 17, 2009

    Agenda for April 16, 2009:

    Items left from April 2 agenda:
    5. Changing pairs:

    1. Should a person be allowed to change their Q/A pairs? YES (thumbs up) . If they know the answers to the original questions, they just change them.
    2. If they cannot answer orig. questions they created, what must they do? Does it matter if they know PID or Hokies passwword?
      1. If IMS/4Help resets password, then if the user cannot remember answers to their Q/A pairs, automatically reset the Q/A pairs and the user will be required to set them up when they go set their password. (thumbs up)
      2. If the user knows the PID or Hokies password, but cannot remember the answers to their Q/A pairs and wants to set up new pairs or answers to existing pairs, what do they do? (wink)  call 4Help, require them to change the pwd, which will clear out Q/A pairs.

    Note - 4Help requires a person to state ID# and 2 other pieces of information to change PID or Hokies pwd.

    Should we require people to enter ID# and (some other information) and birth date to Change pwd online? NO.(thumbs down)

    Should we require people to enter ID# and (some other information) and birth date to create Q/A pairs? YES (thumbs up) PIDgen questions will be used.

    VCOM: During VCOM PIDgen, they must enter ID#, first name, last name, date of birth.

    6. Should VCOM-only PID owners be required and/or allowed to create Q/A pairs, and if so, is their workflow the same as that for a person with a standard PID? Yes, VCOM people will be required to create Q/A pairs during PIDGen time. (thumbs up) If creating pairs after 4Help resets password, should any other information be requested? Will explore whether or not any other useful information is available for VCOM. (wink)

    New agenda items:

    (from #10 in #Items to consider for requirements

    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.

    Is it possilble to prohibit OU Admins from resetting Hokies passwords? Matt: probably not. If an OU Admin directly sets someone's password, the Admin can designate that the person's password must be changed. If 4help resets Hokies password, the desirable process should clear out Q/A pairs just like for PIDs. This may not be possible technically. creation of the pairs can be limited to PID-related activities. If a person can answer their Q/A pair questions, it would be possible to allow them to change Hokies passwords. Is it desirable? One opinion is to limit the project scope to PID, not involving Hokies. Sponsors agree to limit project to PID owners. (thumbs up) If Hokies requirement sufaces later, resetting Hokies password via answering Q/A pairs and eTokens can be added later.

    Wayne - consider Q/A pair security. Links to articles:
    http://www.fishnetsecurity.com/sites/com.fishnetsecurity/downloads/Forgot_Password_Best_Practices_v2.0.pdf

    Designing Authentication Systems with Challenge Questions http://hornbeam.cs.ucl.ac.uk/hcs/teaching/GA10/lec5extra/ch08just.pdf

    Tips for Avoiding Bad Questions http://securityps.infosecmedia.com/whitepapers/TipsforAvoidingBadQuestions.pdf

    Good Security Questions web site http://goodsecurityquestions.com
    A page listing all the resources we have gathered is: Links to Other Resources for Self-Service Password Tools

    Q/A pairs: - Canned questions vs. made-up questions.  What kinds of data do we have in Banner for people?

    Can we use PIDgen questions? No. They are not very secret after a person establishes their PID. What other information do we have in Banner that could be used? None that is not is not discoverable. The Banner information would never be "secret" because too many people in offices have legitimate access to Banner inforamtion in order to do their jobs.

    The answers are the issue, not the questions. Need questions with answers that are subjective. Suggestion to have x number of canned questions, plus an optional made-up question. Sponsors thought this was good.

    Possibly: Pick a picture, pick a phrase, answer some questions. Picture may pose a problem with accessibility. Every image must have a text tag.  How many would be displayed to each user for selection? Upon return, the selected picture would need to be in the set of images displayed to the user. Can research tell us more? Is this too difficult to implement? After initial selection, a group of pictures would need to be presented to the user each time they needed to make a selection. If a random group of pictures is presented each time, but the person's selected picture was in the group, the picture could be guessed. If a limited number of pictures (containing the selected one) was presented, but they were the same pictures each time, each one could be guessed until the selected one was chosen. How secure is this? The consensus was that the increased value of using a picture over a text representation was probably not worth the effort of researching and implementing the pictures.  

    Kevin: one of each (canned + made-up) is desirable.

    Proposal: At least 1 canned question should be used; Yes. (thumbs up)

    SETI TAD would like to do a usability study with live participants creating Q/A pairs using different methods. The resulting sets of questions and answers could be presented to the Secuity Office for a security analysis. Brad said they could determine the bit strength of the selected answers.

  2. Brad Tilley

    Apr 28, 2009

    Since the focus has been narrowed to only PID passwords and since we know the complexity requirements to create or change a PID password (8 chars min, 0-9, A-Z, a-z, special chars, etc.) we can measure the approximate bit-entropy of a minimum PID password. It's roughly 52 bits.

    -----------

    I realized that I made a mistake when calculating minimum VT PID bit-strength. I misread the pidgen requirements. I was under the impression that upper, lower, numeric and characters were required. However, after re-reading the requirements, only three of those four sets are required. Users may use all four sets if they like, but pidgen does not mandate this.

    So, the smallest three sets a-z, A-Z and 0-9 total 62. log2(62) = 5.9 bits per character. A VT PID with a minimum of 8 characters would be roughly 47 bits strong. Probably crackable in about 40 hours or so on a distributed.net style system.

    -----------

    IMO, the process to reset an unknown PID password online (over the Web), should be at least as strong as the password itself. If it is not, it weakens the bit-strength of the PID password. For example, if the method of resetting a PID password is determined to only be 32 bits strong, then as an attacker, I would stop attacking the PID and start attacking the reset process as it would be much easier.

    The hard part may be measuring the bit-strength of the proposed solution accurately. If we can do that, then we can have some level of assurance as to the IT Security of the password reset process.

  3. Marc DeBonis

    Apr 23, 2009

    Actually we can easily dis-allow OU admins from resetting's their OU user's passwords.  Matt misspoke when he said "probably not".  I believe he meant "it would probably not be a good idea".  We specifically delegate the permissions (reset password) to OU admins right now and could remove it.  OU admins enjoy this privilage and probably use it a greater deal, diverting password reset queries away from 4help.