[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slap_sasl_checkpass - why?

slapd should both support external SASL password storage
and in-directory SASL password storage.  slap_sasl_checkpass()
is the former, not the latter.  A configure option or something
should allow the admin to choose.

Kurt


At 07:30 PM 2002-04-15, Howard Chu wrote:
>Still staring at the SASL 2 code in slapd/sasl.c ... The slap_sasl_checkpass
>function doesn't make a lot of sense to me. The checkpass callback is only
>used when SASL is validating a plaintext password. In the context of slapd,
>this can only happen when someone performs a simple bind, and their
>userPassword attribute contains "{SASL}my-username". So, we've already
>specified a valid LDAP DN, looked it up, and found that its password should
>be retrieved from SASL. Now we're going to take that SASL username, and ask
>it to be transformed into a valid LDAP DN, look for that DN's userPassword
>attribute, and try to validate the given credentials.
>
>   ????
>
>If you want to do a simple bind, why not just stick the actual password in
>your userPassword attribute in the first place?
>
>I suppose another way to look at it is a way to allow someone else to login
>to your account using their plaintext password. Is this really a good
>feature to support? (i.e., I set my LDAP entry's userPassword to include the
>value {SASL}dn:someone-elses-DN and then that other DN's password becomes
>valid for binding to my DN.) It's somewhat the opposite of SASL
>authorization, where you bind with your own password and then operate as
>someone else. Seems like a potential security hole to me, but I guess you
>have to go out of your way to screw yourself with it.
>
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support