Securing password resets in web apps

Recently a developer asked me about how he should perform password recovery in his new web app. The first recommendation I had was not to do recovery, but reset instead. I searched for some information aimed at developers on password reset functionality and was surprised at what I found. While I found a lot of information about what not to do, I didn’t find much now what should be done.

After pulling together some of the information I wrote this paper called “Securing Self-Service Password Reset Functionality in Web Applications” in an effort to help educate developers and provide some guidance for them when adding this type of feature to web applications.

Of course, any comments or suggestions are welcome!

Securing Self-Service Password Reset Functionality in Web Applications (pdf)

6 responses to “Securing password resets in web apps”

  1. Brian H. says:

    In your workflow, the user is sent a one-time link after correctly answering the security question. This one-time link can then be used to reset the password with no additional authentication.

    Why not send the one-time link to the user FIRST and then require them to answer the security question AFTER following the link? This would somewhat mitigate the reliance on email as an insecure communication mechanism since the one-time link would still require additional information in order to access the account if intercepted or disclosed to an attacker. As I see it, sending a one-time link as the final step in the process is the equivalent of sending a temporary password via email since it alone can be used to ultimately access the account (within the expiration window, of course).

  2. Chris says:

    I agree, security questions are largely irrelevant these days, in fact I just generate a string of gibberish to put in there and store it in keepass should I ever need to answer them.

    Of course, in the corporate workplace this is a little more difficult depending on what’s allowed and not.

  3. david says:

    @Brian H.: Great idea, exactly the type of input I was looking for. Going in my notes for the next version.

  4. Most of this sounds fine and good for webapps but have you thought about the idea of using a phone number as a way of verification. A cell phone is something separate from email you could send a text with a code in it instead of relying on a secret question.

  5. david says:

    @Eric McWilliams There is a small note in the section about email which mentions using SMS messages as a token, but it I think it should be larger, as I think it is a great way to do tokenless tokens.

  6. I am with you on the tokenless token thing “it should be larger”. I was going to go into a rant on how I think all web sites who do any credit card processing or banking type function should implement some type of SMS or dial back verification. It would be a cheaper alternative than issuing tokens to your user community and more secure than what is currently out there.

    I have been trying to get the auth guys at my company to look at services like Phone Factor instead of using tokens for our VPN. There are SOOOO many auth/access functions you can use a cell phone for its not even funny. If you ask me the idea is just starting to take off and should only get more popular as time goes on.

Leave a Reply