Rather than transmitting a password back to the user via email, it is possible to transmit a key that will allow the reader to change their password via a special page. Transmitting a key rather than their password is better because it doesn't expose a password that they potentially use at other sites and also because this key can be setup such that it is only usable one time. This would prevent a hacker from recording the information and using it at a later time.
Creating a forgotten password key is relatively simple. First, the user's object is "touched" so that some date is changed by the mere practice of sending the forgotten password. Ideally, another property in the user's object will be present which changes every time that the user logs into the system. The user object is then serialized and then hashed using an algorithm like the ones above. This will create a unique key every time the user indicates that they forgot their password because the mere fact that they requested it causes the data to change which in turn causes the hash to change.
It's important to realize that when they do set their password they will be changing the data in the user record of both the password itself and the last updated time. This will automatically invalidate the key that they received making it useless to an attacker for replay or reuse.
By utilizing hashes for password resets it's possible to create a solution which most importantly doesn't give away the user's password but also prevents a third party from replaying or reusing the same key to gain access to the user's account.
It's generally accepted that security account passwords become known over time. One of the established ways used to minimize the impact of this it to cause accounts to change their password on a periodic basis. One of the easiest ways to accomplish this is to set in the record a password expiration date when the password is set. During the logon process it is possible to check the expiration date and redirect the user to change their password if their password is expired.
For accounts that are created for others the password expiration is set to yesterday on creation so that the user is forced to change their password the first time that they log in. Alternatively, the last password set date can be set to a date and a system policy set for how many days can elapse between password change events. In either case it is possible to create accounts with passwords that expire based on business rules as well as accounts whose passwords never expire.
Protecting from an End-Around
A final note on protecting passwords is that sometimes it's necessary to protect the account creation process. If the passwords are appropriately protected but the new account creation process is fairly lax it is possible that malicious parties will try to do a complete end-around the user account/password process by setting up bogus accounts and trying to use them to gain access to the system. When creating a system that protects passwords it's important to consider what validation is done to the account when it is created.
A similar mechanism to the forgotten password mechanism can be used to force a user to validate their account. A hash of important account information is emailed to the account. The user must return to the web site with this information in order for their account to be fully activated. This process can be adapted with an account expiration date that allows a user to use an account for a few days before being forced to authenticate the account. This will minimize the protective effect of requiring activation; however, it will allow users who don't have immediate access to their email to gain short-term access to the system. This technique is also useful with situations where a printed correspondence must be mailed to the user rather than the user receiving an email.
About the Author
Robert Bogue, MCSE (NT4/W2K), MCSA, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert's more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. You can reach Robert at Robert.Bogue@CroweChizek.com.
Page 2 of 2