I’m looking for ideas on how to build a good “forgotten password” system.

I just came up with what I think is an effective and easy solution, but I’m interested in how you do it. User experience and security are, of course, two very important things.

Oh, and ideally an email address would be the login credential, no “usernames”.

Thanks in advance for any good ideas!

If you want you can download Bamboo and take a look at one approach.  The login controller is what you’re interested in.

I’ve not yet done this using CI, but from previous projects -

user enters their username (lost password form)

use that username to look up their email address and user_id,
generate a long random string
put that string into a database (user_id, random_string, clicked)
put a url into the email - eg http://www.foo.com/user/forgotten_password/[user_id]/[random_string]
send email to user.

user receives email, clicks on link
your app checks the db for random_string and user_id, does it find it?

yes
—-
update ‘clicked’ column (this makes the unlock url single-use, added security)
allow user to enter new password

no
—
bogus attempt, fail

Thanks for the replies; they’re somewhat similar to the approach I came up with. I’ve attached a flowchart of my approach.

Why are you adding the extra level of complexity with requiring them to re-enter their email address. This seems unnecessary. I would suggest removing this and making the process as streamlined as possible for the user. If your hash is good enough someone would never get there without clicking on the email link.

P.S. What is bamboo?

Derek’s amazing CI Invoicing Software.

louis w - 07 April 2008 04:04 PM

Why are you adding the extra level of complexity with requiring them to re-enter their email address. This seems unnecessary. I would suggest removing this and making the process as streamlined as possible for the user. If your hash is good enough someone would never get there without clicking on the email link.

Yeah, I’ve thought about doing that. The thing is, you should never assume that no one could ever get there unless they clicked on the link in the email.

Entering your email address is a pretty mindless thing. Also, if you store other unique identifying credentials for your users, you might ask them to, say, enter the last four of their SSN at this stage.

Sean Murphy - 07 April 2008 04:42 PM

louis w - 07 April 2008 04:04 PM

Why are you adding the extra level of complexity with requiring them to re-enter their email address. This seems unnecessary. I would suggest removing this and making the process as streamlined as possible for the user. If your hash is good enough someone would never get there without clicking on the email link.

Yeah, I’ve thought about doing that. The thing is, you should never assume that no one could ever get there unless they clicked on the link in the email.

Entering your email address is a pretty mindless thing. Also, if you store other unique identifying credentials for your users, you might ask them to, say, enter the last four of their SSN at this stage.

Have you done case studies on how other applications are doing it?

You do it almost exactly as we do it.

Asking for the email address on the second round is important because it verifies the hash. Otherwise your hash is as secure as any other random string (ie not very).

It’s important to keep in mind that your system is only as secure as it’s weakest entry point. Often the forgot password is that weak point.

A common mistake is to allow the use of usernames (as opposed to email addresses) If you run a site where usernames are publically displayed all I need to do as a hacker is to harvest those and use them to generate x number of forgot password requests which not only increases their chance of getting access but also is a total nuisance for your users who get flooded with forgot password emails.

Additionally we always encrypt email addresses throughout the system. I like to think that even if someone gained access to the db and watched the table as they generated forgot password requests they still couldn’t then easily gain entry. This also means that using a separate forgot password table rather than your user/profile table to manage the requests is a good idea because it disassociates the generated data from any of your user records.