Attendees:

  • Mary Dunker
  • Daniel Fisher
  • Marc DeBonis
  • Frank Galligan
  • Kim Homer
  • Ken McCrery
  • Brad Tilley
  • Karen Herrington
  • Dean Kirstein
  • Laurel Neidigh
  • Kevin Rooney
  • Rhonda Randel
  • Greg Kroll
  • Ismael Alaoui
  • Susan Brooker-Gross

Requirements discussion:

Agenda:

  • Follow up on topic from August 12, 2008 meeting, where we suggested using some question/answer pairs that utilized information in Banner. Is there any information in Banner other than that used for PIDGen that might be appropriate for self-service password reset?

High school information is available in Banner. IMS will investigate and report back mid-March.

  • Integration with eToken self-service password reset

eToken password resets stats: of 500 eTokens, there were 51 in 2007, 22 in 2006, 41 in 2008, 5 in 2009.  If question sets are shared, eProv would require that, if user can manage/change questions, they would need to authenticate using eToken. Would not want eToken-related questions to be managed using PID/pwd.  If the questions are shared, do no allow user to manage w/PID-level credential.  Option for eToken Q/A is to create them during eToken enrollment.

Questions for eTokens should be kept separate from PId/Hokies questions. Answers should be stored in a one-way hash. Security office agrees.

Where would Q/A pairs be stored? If 2nd set of q/a is for eToken, should the pair be stored in ED registry or elsewhere? If Enterprise data, then it makes sense to put it in ED Registry.

Admissions has a separate question they ask. Potentially, if a user can also call help desk for reset, then we could have a secret question that the Help desk could use. That answer might not need to be one-way hashed. 

 Today, 4Help asks what the ID# is and asks some more questions. For Oracle ID, ID#, name and birth date are questions that are asked. How can we let you know your password was changed? Could send msg to VT Alerts address. VT Alerts may not be an option -- would need to check w/VT Alerts sponsor. Could send to VT e-mail? Sending an e-mail doesn't hurt. If e-mail password different from PID password, the e-mail to user would be valuable.

 types of q/a: 1) for person to use, 2) for Help desk, 3) for eToken

Use case for Help desk-usable pwd to be reversable. Can we record what credential was used to reset or manage the pwd? Yes, we can. Is it useful?

Do we want to facilitate allowing all passwords to be the same?

If you are allowing etoken owner to change PID pwd, you are really changing, not resetting PID or Hokies pwd. We don't want all passwords to be the same. Can we implement some mechanism to ensure the passwords are not the same? YES, but we may not be able to prevent a user from using the PID/Hokies pwd on eToken after initial set.

Need to think of ways to prevent user from learning what one of the passwords is if we prevent the passwordes from being the same. We could have a policy, even if we don't try to enforce it.

At this point, there is no requirement to expand the scope of this project beyond PID, Hokies (and related eToken.) 

  • What questions need to be answered by sponsors and Security Office in order to write requrements?
  1. What are constraints?
  2. What are the assumptions?
  3. What are the policies?
  4. What kinds of usability/accessibility issues need to be addressed?
  5. What are high-level risks? (Need to complete security form for project.)




  • No labels