Using String.equals compare password and authenticate user against LDAP server, Does it make any sense?

Question

I'm working with pretty old, big CMS (TeamSite) and it has an example how to connect it to an LDAP server. I've read the example and it work in very bizarre way. It just store a password in the "userPassword" field as expected but it does the validation manually instead of using the bind command.

This doesn't make sense to me but I can be wrong here as I haven't worked with LDAP servers before. Do you have any idea why somebody would like to manually compare the password instead of using bind?

Here is how the code looks like:

  Attribute attrPassword = attrs.get("userPassword");
  if (attrPassword.size() > 0)
  {
    String storedPassword = new String((byte[])attrPassword.get(0));

    if (password.equals(storedPassword))
    {  
      ///.....

Answer 1

That doesn't make sense to me either. The password in the LDAP shouldn't be the actual password itself, it should be a hash of the password. If you retrieve the field and do a comparison, you need to know what kind of hash it's using and hash the password you're comparing yourself in the same way. It also requires that the userPassword attribute in the LDAP be available for retrieval, which shouldn't be necessary I don't think.

In short, no... I think you should be using bind.

Answer 2

LDAP supports a compare on passwords, but backwards from the way your code seems to be doing it.

Generally, the client trying to compare, provides the password, the LDAP server does the compare, and returns true or false.

Your code looks like it is trying to read the password from LDAP then do the compare in its process space.

This seems unlikely to work with most any LDAP server, unless the hashing method is known and the storedPassword value is prehashed.

You might consider bind vs compare if you want (or do not want) a login event to happen. A login event can be useful to track account activity. (For PCI compliance, for example, you would want people not to be deactivated due to inactivity, which would be determined by logins).