Whats in your LDAP?

Michael L Torrie torriem at chem.byu.edu
Mon Oct 22 18:18:10 MDT 2007


Jeff Anderson wrote [-1 top post, -2 no trim]:
> From my humble and limited understanding of ldap, it in itself isn't too
> picky about who can see the data. Having a hashed password in LDAP
> enables anyone who can authenticate against ldap to see the hashed password.

Well actually LDAP servers usually implement ACLs. ACLs could, in theory
prevent even an authenticated ldap connection from seeing the hash.  But
you are correct; LDAP's protocol has very little in the way of security,
other than SSL covering the connection.

For the reasons mentioned here, Appl's OpenDirectory, for example, has a
kerberos and SASL password store that does authentication, and uses LDAP
only for user information (authorization).

I'll try to find some more formal information on this concept.
Basically it is the OpenLDAP developers who are the most against using
LDAP as an authentication source as well as an authorization source.

> 
> With rainbow tables available, its a better idea to not have your hashes
> public.
> 
> That's why a real authentication mechanism, like kerberos should be
> used. It does not reveal anything about the stored password database
> over the network.

Right.  If you're using a hash field in LDAP for binding authentication,
that means by definition that the password itself has to be passed on
the wire, hopefully with SSL.  This makes it more vulnerable to
man-in-the-middle attacks, and programmer error (forgot to use ssl!).

Finally, note that the real world compels us to implement compromise
solutions.  For example, LDAP simple binds over SSL may be good enough.
Just know there are better solutions.  My departmental servers always
try to use Kerberos first, and failing that (no ticket maybe), fall back
to LDAP binds.

> 
> Jeff Anderson
> 



More information about the PLUG mailing list