Anyone ever do any work or research regarding self-service password reset?

Q:Anyone ever do any work or research regarding self-service password reset?
Hi all,

We are looking to implement a password self-reset service within our organization (for use of internal systems only). The product we are looking at uses a variety of personal questions that need to answered before resetting the password. I was wondering if any of you have ever done any research in this area as to what would consitute an adequate level of confidence into the identity of the user. For instance, what type of questions should be asked, how many, and what percentage of correct answers are required to identify the user, etc. ?

Any help you can provide would be greatly appreciated.


A:Your answer was selected as Best Answer
Your Public Answer:
“Hi ....,
We have had a similar dilemma before.
I recommend segregating initial registration from the password reset. During the initial registration the control should really be tight since the data required has to be something that user knows ( like employee ID, mother's maiden name, etc) that you can pull from HR systems.

We allowed only 2 failed login attempts for registration. Actually the authentication data (questions and answers) for most of the similar deployments came with the ESS portal, You may utilize the ESS database links for the initial questions.

During the initial registration end users can define their own question/answer pairs (this is the one I like). . I recommend this setting if you have single sign on (where the risks are higher).

For password resets we used random 2 user-defined questions. End-users who are trying to see the second question had to pass the first question. We allowed 3 failed attempts at each phase (4th one locks the account, 3rd and 4th trial generate audit trail – remedy ticket)

As a second option you can use pre-defined questions and ask end user to fill-in their answers during registration. We used predefined questions to accelerate the registration process, but this model has more risk than user defined questions&answers. We used questions like "What was your father's first car?" or "Your primary school teacher's first name" We hope that this will increase the chance of limiting access to answers (just an assumption no real data) I do not recommend the questions that are directly related with end-user's real identity (like birth date/SSN/employee ID) which can be tracked.

If you have all windows environment you can use client certificates in order to build bidirectional transparent authentication before asking questions.(easy to deploy on all desktops, will take time for mobile phones/pdas) Certs will help for audit and quick termination.

Another security measure is a text message (SMS) confirmation to user cell phone for each failed attempt, which becomes out-of-band control

That being said the real answer to your question; the numbers (number of attempts for before lock) are not set for any deployment. All I can say is to use the risk assessment that you have performed before, and go through. Let me know if you have any questions. cheers,

- yinal