Re: Forgotten password recovery

[Vincent Panel <yohonet@gmail.com>]

On 2/5/09, Michael Ströder <michael@stroeder.com> wrote:
> Brett Maxfield wrote:
>  > Maybe generate a random challenge, store it in ldap as an additional
>  > hashed password value maybe with a special {challenge} hash type as a
>  > marker, assuming ldap will try *all* passwords when logging in.
>
>
> Implementing this with multi-valued userPassword will raise some issues
>  when sorting out the temporary challenge-password later (either if it's
>  used or not used by the end user).

Well, yes and no : once the user is logged in, it is granted all
necessary rights to do the cleanup of additional passwords. If they
are marked with {challenge} or something similar, then it's easy to
clean them up. But I agree it's an additional thing to implement and
think about.

> I'd go for separate LDAP entries
>  where you can store additional expiration information.

At first, I thought Brett's solution was cleaner (only one database,
no ugly regexp-based ACL, etc...). But then, I found out it may pose
some security risks : drupal has to be allowed to create those
additional userPassword values. If this account is compromised, every
user can be impersonated easily.

Then I came back to the other solution with a separate database and
asked myself what were the differences between Brett's solution and
this one from a security point of view. And I found none : by
compromising drupal's account, you are still able to create temporary
security objects with whatever password you choose and then bind as
this temporary security object to reset the user's password and
impersonate the user ; and you're able to do this for any user.

Now I'm back to the start : there's no mean to prove to openldap
you're the right user without having your user/password pair or
requiring the assistance of a more privileged user (in our case,
drupal's dn).

Unless I write a new overlay in openldap which handles the mail
challenge itself...