Password resets have historically been handled by the 4Help department.
A user requiring a password reset would call 4Help, who would ask demographic questions to authenticate the user.
Upon authentication the user's password would be reset to a temporary string and the user required to immediately set the password.
The problem of self service password resets came to us because some users do not have access to a phone and still need to perform password resets.
Additional background: In September, 2003, comments from the Board of Visitors were discussed at the VP for IT's staff meeting. Those comments reflected that the BOV thought VT should periodically require PID password resets. A potential schedule was discussed for phasing in password resets, but there was no follow up on the plan. Providing a self-service passwowrd reset tool would facilitate password resets, whether they be en-mass or individual. Conversation between SETI director and the VP for IT in June, 2006, confirms that the BOV believes our password reset practices need improvement. VP for IT suggested using multifactor authentication to allow user to reset password. Mary B Dunker 2006/07/14
Comment: We may not need for all methods of authentication for password reset to be the same. Mary B. Dunker 2006/07/14
With the advent of personal digital certificates with private keys stored on smart devices, a solution utilizing multifactor authentication should be evaluated to allow a user to reset their PID password. Mary B Dunker 2006/07/14
All password resets require some degree of demographic data, how much depends on how strong you want your authentication to be.
Asking users their name, id number, and/or birth date are commonly used attributes.
Other one-off data may be used as well, like mother's maiden name or father's birth date.
Using demographic data as the sole means of authentication would not be very secure and is NOT recommended due to the ease as which other people's data can be obtained.
Answers to demographic questions should also be weighted if questions include data that is generally available in public directories
(so that knowing your id number is worth more than knowing your middle name).
Coupling demographic data with some form of user contributed data can help strengthen authentication and is strongly recommended for inclusion in the password reset functionality.
However users must be told that password resets cannot occur until they have set some number of question/answer pairs.
(This process could be enforced at PID creation, or when a phone reset is made.)
A set number of correct answers should also be required.
For example, if we store 5 question/answer pairs, then requiring 3 correct answers and no incorrect answers should be enforced.
Adding an out-of-band component to the self service password reset has the benefit of reducing abuse.
For example, if an email must be received to begin a password reset, then an attacker must also intercept the email in addition to knowing a user's demographic data and question/answer pairs in order to falsify a password reset request.
It is assumed a user attempting a password reset does not have access to their email account, so we would need to provide users a way to set an alternate email account.
In addition, we need to be able to verify that the alternate account functions and belongs to that user.
(This is similar to what a listserv does when it receives a subscription request.)
We should not focus solely on password resets made from a computer.
With the proliferation of phone based devices for online use, it would not be hard to contrive an example of a user needing a password reset who only has access to a phone.
If we are to keep phone based resets it is important that the authentication process for a phone reset be the same as a computer reset.
This can be accomplished by having 4Help personnel use the password reset tool on behalf of the user or by adding a VoiceXML interface to the password reset business logic.
Any self service application has the potential for abuse, particulary those which can lead to identity theft.
This tool should be particularly aware of these threats and take every precaution regardless of the impact on ease of use
(i.e. resetting a password should not be easy or convenient).
Enforcing a lock out on the reset tool due to failed activity is one way to prevent brute forcing a reset.
The lock out should be very stringent since it only affects that user and the reset tool, it does not affect authentication
(perhaps as low as one or two failures resulting in a 15 minute lock out).
Lastly, an audit trail should be produced showing when a user completed or failed a password reset.
<Add your comments here/>