[Cosmo-dev] "Forgot Password" workflow

[Travis Vachon]

Hi folks

I started down the path toward implementing this and realized that as  
proposed we would need to store a "password reset id" in the database  
so that we know, given a url containing the id, which user we are  
changing a password for. Given that a) we don't have this now and b)  
password reminders used to work, this seemed strange. Looking at the  
old (struts) implementation it looks like we were using the following  
model:

1) User enters username/ email address
2) Password is reset to random string and sent to user
3) User can log in with new random password and change to new  
password if they want.

One downside of this is that a user's password can be changed by any  
random person, albeit to a random string that only the appropriate  
user should be able to access. Another is that they need to remember  
the temporary password until they log in, and then change to whatever  
password they would like to stick with.

One upside is that we would not need to add anything to our data  
model. With my proposal, I imagine the best thing to do would be to  
store a "password reset id" in the User object and make it indexable  
so that Users can be looked up by password reset id.

Any thoughts on these two options?

Travis


On Mar 12, 2007, at 12:22 PM, Travis Vachon wrote:

> Hi folks
>
> I'm about to get back to implementing this (bug 7709, http:// 
> tinyurl.com/32akg5), and just wanted to recap/ propose a final  
> design for this workflow:
>
> Users of the Cosmo WebUI will forget their passwords. When they do,  
> they will be able to click on an "I forgot my username or password"  
> link on the login page. This link will display a "forgot password"  
> dialog/ screen that will have two fields: Username and Email  
> Address. Users can enter either one or the other (if they enter  
> both, the application will act as if they only entered Username)  
> and click "Send a reminder email".
>
> If the Server receives a request for a password reminder by  
> Username it will look up the email address associated with that  
> Username and send an email containing a password reset link.
>
> If the Server receives a request for a password reminder by Email  
> Address it will look up the Username associated with that Email  
> Address and send an email containing the Username and a password  
> reset link.
>
> Once a user clicks on a password reset link, they will be taken to  
> a special "password reset page." They will not have access to any  
> authenticated part of the app. The password reset page will have  
> two inputs: Password and Confirm. Users must enter the same string  
> in both boxes, after which they will be reminded to change their  
> client programs (Chandler, iCal, etc) and automatically logged in  
> to the WebUI.
>
> Abbreviated:
> 1) User clicks on "Forgot username/password" link
> 2) User enters username and/or email address and clicks "send  
> reminder"
> 3) User checks email, clicks on forgot password link
> 4) User enters new password, is reminded to change passwords in  
> client programs, is logged into app
>
> A couple notes:
>    * While the "temporary ui access" would certainly be useful in  
> some cases, and doesn't seem to me to be less secure than allowing  
> users to reset their passwords by clicking on a link in an email,  
> I'm not sure it is needed within preview timeframe. In addition, it  
> would be at least twice the work since we don't currently have the  
> auth/z infrastructure to support it on the backend (largely because  
> of the way we use Basic authentication for CMP user self  
> administration).
>
>    * It might be a good idea to use a "security question" (what was  
> the name of your first dog's mother's owner's oldest cousin?)  
> before sending the email and/or resetting the password.
>
>    * It might be a good idea to use a Captcha (http:// 
> en.wikipedia.org/wiki/Captcha) before sending the password reset  
> email to preven bots from generating superfluous password reset  
> emails.
>
>    * Language on the links is definitely not final, and will be  
> polished iteratively with the design team during implementation.
>
> PPD input would be very much appreciated on all three notes and the  
> workflow design, and comments by all interested parties are  
> requested. Please reply to cosmo-dev.
>
> Thank you!
>
> -Travis
>
>
> On Feb 20, 2007, at 11:46 AM, Brian Moseley wrote:
>
>> On 2/15/07, Jared Rhine <jared at wordzoo.com> wrote:
>>
>>> - Password "reset" is all well and good, but the process isn't  
>>> complete
>>> until the user has changed their password again.  They aren't  
>>> going to
>>> remember just a reset password, and the places they have a password
>>> entered (like Chandler account dialog) need to be updated to.
>>>
>>> So question: instead of "click a link to reset", would it be  
>>> better to
>>> "click a link to go to a page where the user can enter a new  
>>> password"?
>>>   After the password change form, they should be logged right in.
>>>
>>> We might even want to remind them that their clients need to be  
>>> in sync.
>>
>> +1
>>
>>> I tend to think that the above approach of "click here to change  
>>> your
>>> password", forcing a password change, and then being logged-in
>>> accomplishes the same effect.
>>
>> i agree, and i'm pretty uncomfortable with the notion of letting
>> somebody into an account without them providing any credentials.  
>> sure,
>> they had to receive an email with a special link in it, but almost
>> nobody uses securely transported email either.
>>
>>> However, "forcing a password change" doesn't cover the case that
>>> Foxmarks' design does, of where they are trying to access the web  
>>> UI and
>>> have just forgotten their password.  They get temporary web UI  
>>> access by
>>> clicking on the link, and they can just leave their client as it is
>>> (since their client probably has the right password).
>>
>> i'd rather not go this far until we see a huge demand from our users.
>> _______________________________________________
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev