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 > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
