[Freeipa-devel] [RFC] Self-service Password Reset

[Simo Sorce]

On Thu, 2015-06-25 at 15:19 -0400, Drew Erny wrote:
> 
> On 06/25/2015 03:13 PM, Drew Erny wrote:
> >
> >
> > On 06/25/2015 03:07 PM, Simo Sorce wrote:
> >> On Thu, 2015-06-25 at 14:40 -0400, Drew Erny wrote:
> >>> Hi, All,
> >>>
> >>> FreeIPA's most requested feature just got a proposal.
> >>>
> >>> Check it out at 
> >>> http://www.freeipa.org/page/V4/Self_Service_Password_Reset
> >>>
> >>> I eagerly await your explanations of why this is a terrible idea.
> >> Well clearly it is a security nightmare :-D
> >> Anyway point 6, it is better to not send any password via email.
> >> I see 2/3 options here.
> >> 1) Just show the user the new password and a link to go and reset it.
> >> 2) Just redirect the user to the Self-Service Password change page and
> >> pre-fill the "old password" fields with the newly minted password.
> >> 3) Provide a password change with hidden old-password fields straight on
> >> the self-service portal.
> > I think when I was running this past my peers, they mentioned these 
> > concerns, and I must've forgotten to update the draft.
> >>
> >> While 2 would be somewhjat nice it is probably difficult because of CSRF
> >> protections in FreeIPA, and besides if you already have the password you
> >> might as well just use it immediately and save the redirect. So I would
> >> prefer 3.
> > I prefer 3 as well; I'll amend the draft right now.
> >>
> >> Simo.
> >>
> >
> 
> Sorry, I jumped the gun on replying to this email and forgot to sanity 
> check it.
> 
> Option 3 won't work, because when anybody who is not the user resets the 
> user's password (including admins, IIRC), the user is prompted to reset 
> their password upon first login. So, if the user sets a new password 
> straight on the self-service portal, they'll have to change it 
> immediately anyway, because the self-service portal will be the "user" 
> resetting the password, not the actual user.

This is not how it works.
Follow these steps:
1. check that the user used a link with the proper unique reset code in
the path on in the query arguments, and validate the link is not
expired.
2. immediately remove the reset token from the db.
3. generate a random password
4. use the service keytab to authenticate and reset the user password to
the generated random password.
5. present the user with a form to enter his new password (a hidden
filed will contain the random password as old password).
6. perform a password reset where the old password is the one you
generated in (2) and used in (3) and the new password is the one the
user gave you.

You will basically go through 2 password changes (one administrative,
and one normal), but it's ok.

Make sure to be able to retain the password until the password change is
successful, as the user may fail to change the password if the new one
does not meet policy requirements, so you'll have to display errors and
be able to retry.

> Option 1, just displaying the password to the user, is probably actually 
> best. This way, they copy the password, paste it into the FreeIPA webui 
> login form, and then get kicked into the FreeIPA webui password reset 
> workflow, instead of setting a new password just to have to change it. 
> We can show the password with a big message that says, "USE THIS 
> PASSWORD IMMEDIATELY. IT WILL NOT BE AVAILABLE AGAIN."

It's more error prone and does not give you any better outcome.

Simo,

-- 
Simo Sorce * Red Hat, Inc * New York