Knowledge Base/Support & Answers

Automated password recovery?

Tiago Soromenho
posted this on March 14, 2011 09:53 am

QUESTION:

How can we implement an automatedf "forgot your password?" password recovery process at the login screen?

 

ANSWER:

The password recovery tool that used to exist in the Dashboard was removed a while ago because of issues regarding who the sender is (Client? Agency? certainly not StickyStreet yet that's who actually sends it.)  Likewise on the hotsite: Many hosting providers limit the ability to send out emails through code (for the obvious to mitigate spam) and so providing a feature that wouldn't work in most cases, or would require as much technical time and ability as to custom implement it, was deemed both unacceptable in terms of user experience, nor worth the time and effort to develop.

However, given that hotsites are hosted on a provider of your choice, there's no reason that if the ability exists, you can't adde such a capability to your deployed hotsites.

Since each hotsite is unique to a client (the account_id and user credentials are hard coded into the configuration file)  all is there that is needed to be able to properly implement a password recovery capability that is securely keyed to that one account, without requiring the customer to choose from a pull down of participating businesses.

As one of the security standards to which we adhere to, passwords are encrypted and are not able to be retrieved from the database. There is no way for us or anyone else to manually retrieve a password, since the encryption is one-way and cannot be reversed.

Also, we do not recommend that the password rest functionality exists solely on the stie, without tying it to an email or some sort of verification of the user's identity.  Imagine this scenario of a poorly implemented password reset: A person finds a lost card on the floor. They go to the site, request that the password for that card # be reset and the new password is shown on the screen or they are then automatically logged in to the account.  You can see this is wrong on many levels. One should not be able to reset a password just on the basis of knowing the card # or member ID.  There has to be some additional form of verification that the user is really the original owner of that account.

The most common way to do this is to check if they have a email associated with the account they claim to have lost the password to, and email them the reset, random password. They can they use it to log in and change it to something else.

You can accomplish this using either the User Update or Customer Update API call depending if ou are resetting a user password on a hotsite for clerks(users) or for customers:

An alternative to the email is to ask for some information that is already in the system, such as a phone number.