Secure Password Reset Techniques For Managed Services

Managed service customers always seem to need password resets. While the technical aspect of resetting a password is easy, the security and procedural side is not as straight forward. However, with a few tweaks to reset procedures, both security and client satisfaction can be achieved.

The main difficulty as a MSP is verifying the identity of who is making the request. Traditionally users will call in or use a text based ticketing or email system to put in a reset request. Since neither voice nor text can verify the identity of a person, additional methods are required. Here are a few that tend to work well:

• Have a primary contact. A primary contact is useful for many things, but such a person is especially useful for facilitating password resets. This contact should be a trusted manager/owner who knows the identity of everyone in the company. If all password resets go through this person, it makes verifying the identity of the person making the request much easier, and it also transfers the risk of a phishing or malicious reset to the client.
• Enforce secure call back. This goes hand in hand with a primary contact, but it can be used with stand alone contact lists as well. With secure call back, every user that puts in a reset request via call/email receives a call from the phone number that is on file for that user. The return phone call will reasonably verify the identity of the person on the other end.
• Connect to the system. Most MSP’s have remote connection ability, so remotely connecting to a PC generally isn’t too burdensome. Not only does remotely connecting to a system help diagnose the issue, it can also verify that this is an end user and not a phone phishing attempt.

Once the validity of the reset is determined, resetting the password is very simple. However, a few things can be done to promote good security:

• Force the user to change the password. This is easier to do in an Active Directory environment than a Workgroup environment, but it can be done in both. Making the end user change the password after it is reset offers liability insurance, as then the only one with login credentials to the customer’s accounts is the customer.
• Use a random generator where possible. If a password must be transmitted over an unencrypted channel (like traditional email) or if a password is for a service account that will be saved and not need to be entered again, random generation is advisable. Random passwords aren’t very user friendly, so end users will likely change them (and thus when a client will be less likely to use the potentially compromised password in daily production). PWGen is an open source password generator, and it can create random passwords in bulk.

It seems that password strength and complexity questions arise as passwords are reset. Perhaps the customer asks for the password to be reset to something specific, and their requested password is horribly insecure. While it might be ill advised to force the customer to use something more secure (as they will forget it, and a vicious cycle of forgetting and resetting will start) it is a prime opportunity to educate customers about secure password practices (or perhaps the use of a password manager).

As a final note, documentation is essential for password resets. Whenever a request comes in, it is advisable to document who made the request, what account is being reset, if the password was reset to something generic or something specific, and if the user will be forced to change the password. This is especially useful for clients who have generic accounts (such as “frontdesk” or “customerservice”) that would be used by multiple end users. It is also wise to provide customers with a copy of the password reset policy that will be followed when a reset request is made, so that they will be aware of the process (and not unreasonably disgruntled by the extra security precautions). Combined with the methods above, good documentation will make password resets a secure and more efficient task.