In my first implementation of password reset, a user just entered their email address and they were sent a new password. Unfortunately, this meant that an unsavory person could just keep entering your email into the application, resetting your password and by-and-large being, well, an unsavory person.
Originally I had intended next implement security questions in order to allow users to reset their passwords. However, I had a lot of design decisions about how to support and implement this both in terms of functionality and usability. While I think security questions are ultimately a superior approach, I opted for an easier approach.
The current solution is to send user’s reset password confirmation key to their email account. Upon receipt, they can return to the site and with their email address and confirmation key in hand request their password be reset. At this point the original flow is followed; namely, we create a random password and send it to you in email.
The advantage to this approach is that it leveraged extant functionality in the user model, thus requiring a minimum of coding. However, the one down-side is that resetting your password requires you to use both Kotoba and you email client. Security questions would obviate the need for email and make the whole user experience better.
Nevertheless, expediency won the day. For now.