Self service password reset in large organisations

Feature by Mario Guido Finetti

It is more and more common to see a "Forgot your password?" link in every login form, both in internet websites and in corporate intranet applications. Many different self-service password reset procedures exist, with subtle differences.

It is more and more common to see a “Forgot your password?” link in every login form, both in internet websites and in corporate intranet applications. Many different self-service password reset procedures exist, with subtle differences. Generally speaking, they all rely on one or more of the following information: pre-registered email accounts, pre-registered phone numbers and pre-registered life questions, also known as challenge questions (e.g.: “Which was your first school?”). Solutions relying on email are not viable in the enterprise environment, because a user's mailbox is often protected by the same lost password. Likewise, large organisations generally do not provide each member with a mobile phone. Relying on landline phone numbers is also an option but may prevent mobility (see related links).

Solutions relying on challenge questions are always feasible, but may lack security if the challenge question is used as the only authentication factor. Many software vendors offer a self-service password reset solution based on multiple pre-registered challenge questions and, possibly, additional questions on personal information available in the corporate database. This approach does not entirely prevent a “social engineering” attack and puts a considerable burden on the users.

Taking advantage of human relations

A better option is available: taking advantage of the network of existing human relations among users, as proposed by RSA Laboratories (see related links). Instead of calling the helpdesk, users who forget their SecurID token – but not their PIN – should contact one person in their “helpers” list. The “helper” is a colleague who knows the “asker” in person and who is authorised to support him in case his SecurID token is not available.

When the asker calls the helper, the helper accesses a special application and authenticates by entering the passcode generated by his SecurID token along with his PIN. The helper then enters the userID of the asker and gets a secret code back, called “vouching code”. The vouching code is then given to the asker. The asker connects to the same application and authenticates by entering the vouching code and his PIN. He is then prompted to choose a temporary password to be used instead of the one-time passcode that is normally generated by the RSA SecurID token.

This solution is extremely secure and requires neither helpdesk support nor pre-registered challenge questions.

A solution to the Windows password reset problem

A similar approach can also be applied to the Windows domain passwords. The solution described here was aimed at reducing password-reset calls to the helpdesk of a large company and it is now live for approximately 15,000 employees.

Users are required to register a single challenge question and the correct answer. If they forget their Windows password, they need to ask one colleague for assistance. The helper colleague could be anybody in the company who knows the asker in person and who is close to him when he needs to reset his Windows credentials.

The helper and the asker need to share the helper's PC and follow the steps below:

  1. The helper authenticates to the password reset web application
  2. The asker enters his personal user ID in a HTML form
  3. The challenge question is then shown and the asker needs to enter the correct answer to proceed
  4. If the answer is correct, the asker is prompted to choose a new password (or a temporary password to be changed at first logon)
  5. The asker returns to his seat and accesses his PC by entering his new credentials. No change was required to the standard Windows logon experience
  6. An automatic email is sent to the helper, the asker and the security officers notifying that the password reset procedure was activated. Since the helper authenticates to the password reset application by entering his credentials, he is responsible for any abuse.

This solution does not require helpdesk support and can be used even by employees on business travel, provided that they travel with colleagues.

Design issues

Writing a comprehensive threat model is highly recommended if you are going to implement a reset password solution in your company. The paragraphs below only describe a couple of design issues I found particularly interesting.

The PC sharing dilemma
This solution assumes that corporate PCs are trusted machines and that helpers are trustworthy people. RSA Labs' solution instead, is carefully designed in order to avoid PC sharing.  Generally speaking, PC sharing should be avoided because a malicious helper could install a key logger on his PC and capture the asker's credentials. On the other side, key logging on untrusted PCs is a problem with password-based authentication in general, even if no vouching system is in place. Also, in the Windows password reset scenario, PC sharing has some benefits: it forces helpers to authenticate askers face-to-face.

Who can help who?
The helpers list is another important aspect in the design of a vouching solution. You need to define which users will be entitled to act as helpers for a given asker. There is a trade-off here. On one side, it is important to prevent a malicious asker from getting in touch with naïve helpers who may assist him even if they do not know him. On the other side, restricting the list of authorised helpers too much means that askers will have no other option than getting in touch with their helpers over the phone or, even worse, via email. Since the helper is responsible for vouching for the asker's identity, face-to-face recognition should be the only option.


From a user perspective, the self-service password reset application was a minor extension of a pre-existing web application managing user's profile data, including the challenge question. This web application was based on a Java Enterprise Edition application server running on Unix servers – not the best platform to deal with Microsoft Active Directory. Therefore, a new Windows-based backend service was developed for this purpose.

Front-end web application (Java EE)
This application allows every employee to insert or update his challenge question along with other personal information not relevant to this article. New web pages were developed to manage the reset password process described above.

Front-end application is responsible for user authorisation. Business rules regarding who can act as a helper and who can act as an asker are implemented here. At the end of the process, the web application calls the backend service described below that is responsible for setting the new password.

Backend service (ASP.NET)
This is a simple SOAP over HTTP web service implemented as an ASP.NET application running on Microsoft IIS. The input parameters of the “set password” operation include: asker's ID, new password and few options. From a security perspective, the front-end application acts as a trusted subsystem and the backend service completely relies on it.

Mutual authentication between the front-end application and the backend service is achieved by SSL/TLS with client authentication. OASIS Web Services Security was not used, since the front-end application is the only consumer of this service and there are no intermediaries between the two parties.

Active Directory is responsible for enforcing the security policies applying to passwords in general. If the asker chooses a short password, for example, Active Directory rejects it, the web service returns an error message and the front-end application notifies the user.

For the sake of reliability, the interaction between the front-end application and the web service follows the synchronous request-reply pattern. In the unlikely event of communication problems between the front-end application and the backend service, the front-end application alerts the user and invites him to try again. In case the front-end application does not receive any response after the new password is set, a new redundant request may be submitted. However, since the password setting operation is idempotent by nature, double requests do not create any problem.


Find this article useful?

Get more great articles like this in your inbox every lunchtime

Upcoming Events