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

[Alexander Bokovoy]

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.


-- 
/ Alexander Bokovoy