[Cosmo-dev] "Forgot Password" workflow

[Travis Vachon]

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