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.
openldap would need to know the marker {challenge} hash type is like {plain} or some other hash type for purposes of comparison.
You cannot allow reset of a password (destroying the old one) immediately, as otherwise you are allowing a denial of service attack where people could randomly reset passwords.
But given the random challenge (returned by the user) could now be used for authentication, the user could authenticate as themselves and reset thier own password, and remove the temporary challenge password.
This probably requires a marker "hash" type to identify temporary hash password, to allow reliable removal of old or expired challenge passwords.
-----Original Message----- From: Vincent Panel yohonet@gmail.com Sent: Thursday, 5 February 2009 1:59 AM To: openldap-technical@openldap.org Subject: Forgotten password recovery
On 2/4/09, Michael Ströder michael@stroeder.com wrote:
Yes, but these "temporary security objects" have to be generated. If you do this automagically you have a privileged service account which resets the user's password in combination with a e-mail based challenge-response check.
I agree, but until I get your replies, I did not find any satisfying solution integrating this "e-mail based challenge-response check". I wanted the ldap server to validate the challenge which is going to be possible if I make drupal create those security objects with the challenge answer as the password.
Once a user comes back with its response to the challenge, drupal will try to bind to the LDAP server as this temporary security object with the password being the "challenge" url. If the bind is successful, then drupal will automatically be granted the right to reset the corresponding user's password (thanks to regex ACLs). Once this is done, the user will be able to log in (or actually, drupal will log the user in)
This is probably a bit complex to implement, but I'm gonna try.
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). I'd go for separate LDAP entries where you can store additional expiration information.
Ciao, Michael.
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...
openldap-technical@openldap.org
-
Brett Maxfield -
Michael Ströder -
Vincent Panel