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
>>> 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.
Sorry, I jumped the gun on replying to this email and forgot to sanity
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
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,
However, this requires that you have password policy which allows
subsequent password changes in a short time period.
/ Alexander Bokovoy
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code