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...