Effective Techniques for Password Retrieval in Modern Web Applications

Question

We've been working on web application where in we need to implement traditional web-apps functionality of password retrieval. According to the trends there are approaches like..

1. Sending Password reset link to user's email.
2. Asking Secret Question to the user for Password recovery.
3. Resetting the existing Password and creating a new password and sending it to the user. This may also force the user to change the password upon next logon.

Do we have any non-traditional technique for implementing password retrieval mechanism ? What other approaches you've tried for this ?

Thanks.

Answer 1

It depends on the the level of security you are aiming for, support costs and usability concerns.

Emailing a password reset link is the preferred approach for a number of reasons:

• Support Costs - This is the biggest factor from a business perspective. Users often forget even their password hints or use a fake mailing address or forget their user name. All of these are legitimate concerns for which you might get support requests. This in turn creates another issue, you have to establish the legitimacy of the user by asking them about recent account activity and what not. If you don't provide that level of support a lot of novice users will be disappointed. Emailing a password reset link mitigates these concerns because the users typically have one or two email addresses and they can easily recover their username/password by providing their email address.

• Security Concerns - This is the biggest factor from a technical perspective. There are various concerns here which you have to weigh. A compromised email account means the hacker can go to access all of the users' services which allow a password reset link to be emailed. You can settle for middle ground which is to email a password reset link to the user which in turn asks the user a password hint question after which it allows them to reset their password. Again, you should never expose the user's password in any medium. In fact, if you have the capability to show them their password your system is already insecure because it implies you are not storing them using a secure hash like SHA-1 and a developer in your company can get at everyone's password.

• Usability - This is the biggest factor from the user perspective. Emailing a password reset link requires the user go and check their email address which can means the time to achieve the task can go up to 2 or even 3 minutes. However, I would think that this is not a big deal. Most users don't seem to mind this because they feel they are at fault and this is a security measure in their best interest. I am only hypothesizing from personal experience and users in general might feel differently. I would put security as a higher priority than the user experience because users will rarely if ever need to retrieve their passwords (user has not logged in for a long time and forgot his password; user had saved his password in the browser which was reinstalled and some other edge cases).

Answer 2

Other options I saw in practice would include:

• allowing a second password when something goes wrong - something like the Super-PIN used with cell phones.
• creating a file token(usually a PGP key) that the user will download at account creation and store it on a USB Stick, or archive it for later use. When there's a problem the user will upload the token, thus proving that he is the "owner" of the account, and the application than will let the user to change the password. This can be a constant token, or a file with several tokens (similar to an online banking TANs) - each time a token is used, it's also invalidated.

The above methods are not that simple to implement, but are quite user friendly (since there's nothing new about them and are present other in day by day situations).

Answer 3

In my opinion, sending a password reset link to the user's email is the best way. This is the way Digg does it, and this is the way I do.

But in this method we need to rely on the user being able to access his email.

Regarding the secret question method: more often than not, the secret question's answer is not as secret as we would like. It would be in the best interests of our users to block this method of an "account-hack".