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

[Simo Sorce]

On Thu, 2015-06-25 at 23:43 +0300, Alexander Bokovoy wrote:
> On Thu, 25 Jun 2015, Simo Sorce wrote:
> >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.
> This is what I suggested multiple times in past, see for example,
> http://www.redhat.com/archives/freeipa-users/2012-June/msg00360.html
> 
> However, this requires that you have password policy which allows
> subsequent password changes in a short time period.

The administrative reset should not cause the password change blackout
period. If it does it is something we should consider fixing/changing.

Note that if that's the case, a manual approach will be no better as the
user won't be able to immediately change the password as well.

Simo.

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