Directory ApacheDS
  1. Directory ApacheDS
  2. DIRSERVER-997

Block search ability for userPassword attribute

    Details

    • Type: Improvement Improvement
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: pre-1.0, 1.0-RC1, 1.0-RC2, 1.0-RC3, 1.0-RC4, 1.0, 1.0.1, 1.0.2, 1.5.0, 1.5.1, 1.5.2
    • Fix Version/s: 2.0.0-M8, 2.0.0-RC1
    • Component/s: None
    • Labels:
      None
    • Environment:
      All

      Description

      I entered this issue on request from the user list where this topic came up.

      The userPassword should not be available for search,
      else password fishing is possible.

      If you are allowed to do a search like
      $ ldapsearch -b o=some.root -s sub 'userPassword="

      {md5}

      b4b5835f03bd6748e0cc25790d6f3498"' dn
      it would render you all objects with the attribute userPassword equal to
      "the secret password", which may not be such a good idea.

      iPlanet DS 4.x allowed searches on ueserPassword attribute with
      directory manager privs I found out.

        Issue Links

          Activity

          Hide
          Ersin Er added a comment -

          Hans, this is related to how you configure Authorization. You can deny users for doing anything with passwords if you want. I don't think this is an issue to be fixed. It can just be done via configuration. You may have a look at:

          http://cwiki.apache.org/confluence/display/DIRxSBOX/Draft+-+ACI+Based+Access+Control+-+Step+by+Step+Guide

          Show
          Ersin Er added a comment - Hans, this is related to how you configure Authorization. You can deny users for doing anything with passwords if you want. I don't think this is an issue to be fixed. It can just be done via configuration. You may have a look at: http://cwiki.apache.org/confluence/display/DIRxSBOX/Draft+-+ACI+Based+Access+Control+-+Step+by+Step+Guide
          Hide
          Ersin Er added a comment -

          Well, although I think you do not refer to this issue can also be considered with one of our existing issues: DIRSERVER-955. If you suppose that we fixed this issue, with appropriate configuration (the one I mentioned in the previous post) no one can use userPassword in a search filter not they can read values from that attribute. Such a search operation would need grantFilterMatch and grantRead permissions on userPassword attribute.

          Show
          Ersin Er added a comment - Well, although I think you do not refer to this issue can also be considered with one of our existing issues: DIRSERVER-955 . If you suppose that we fixed this issue, with appropriate configuration (the one I mentioned in the previous post) no one can use userPassword in a search filter not they can read values from that attribute. Such a search operation would need grantFilterMatch and grantRead permissions on userPassword attribute.
          Hide
          Hans Lohmander added a comment -

          Yes, the issue DIRSERVER-955 would handle this and more. Then it comes down to a sensible default configuration for the userPassword attribute.

          Show
          Hans Lohmander added a comment - Yes, the issue DIRSERVER-955 would handle this and more. Then it comes down to a sensible default configuration for the userPassword attribute.
          Hide
          Emmanuel Lecharny added a comment -

          We need to add some documentation, and also to add the proposed configuration as a default value in the server.

          Show
          Emmanuel Lecharny added a comment - We need to add some documentation, and also to add the proposed configuration as a default value in the server.
          Hide
          Emmanuel Lecharny added a comment -

          To be fixed in the next release

          Show
          Emmanuel Lecharny added a comment - To be fixed in the next release
          Hide
          Alex Karasulu added a comment -

          This is a security issue that should be fixed quickly.

          Show
          Alex Karasulu added a comment - This is a security issue that should be fixed quickly.
          Hide
          Ersin Er added a comment -

          Well, we can handle this in DefaultAuthorizationService I think. It can be a hardcoded check as no one will want to allow such a search.

          Show
          Ersin Er added a comment - Well, we can handle this in DefaultAuthorizationService I think. It can be a hardcoded check as no one will want to allow such a search.
          Hide
          Ersin Er added a comment -

          This issue is just a specific case of DIRSERVER-955.

          Show
          Ersin Er added a comment - This issue is just a specific case of DIRSERVER-955 .
          Hide
          Alex Karasulu added a comment -

          Looks like you got this on the roadmap.

          Show
          Alex Karasulu added a comment - Looks like you got this on the roadmap.
          Hide
          Alex Karasulu added a comment -

          Next release - we need to get 1.5.4 out fast.

          Show
          Alex Karasulu added a comment - Next release - we need to get 1.5.4 out fast.
          Hide
          Emmanuel Lecharny added a comment -

          I have added some code into the place where we build the responses : if the userPassword is present, and if the server does not allow this userPassword to be exposed, then the attribute is removed from the response.

          i think this is a mid-term solution which is pretty easy to implement.

          However, we need to add a flag in the server configuration to tell the server to hide the password.(or it can be the default, and then we need a flag to tell the server to expose the password...)

          Show
          Emmanuel Lecharny added a comment - I have added some code into the place where we build the responses : if the userPassword is present, and if the server does not allow this userPassword to be exposed, then the attribute is removed from the response. i think this is a mid-term solution which is pretty easy to implement. However, we need to add a flag in the server configuration to tell the server to hide the password.(or it can be the default, and then we need a flag to tell the server to expose the password...)
          Hide
          Emmanuel Lecharny added a comment -

          Postponed to 2.0.0-RC1

          Show
          Emmanuel Lecharny added a comment - Postponed to 2.0.0-RC1
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Version 2.0.0-M1 has been released.
          Moving all related non-resolved issues to the next version.

          Show
          Pierre-Arnaud Marcelot added a comment - Version 2.0.0-M1 has been released. Moving all related non-resolved issues to the next version.
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Version 2.0.0-M3 has been released a couple months ago.

          Assigned the remaining opened JIRA to the next iteration (2.0.0-M4).

          Show
          Pierre-Arnaud Marcelot added a comment - Version 2.0.0-M3 has been released a couple months ago. Assigned the remaining opened JIRA to the next iteration (2.0.0-M4).
          Hide
          Emmanuel Lecharny added a comment -

          Please do not close issue you don't own, especially if the issue is still present !

          Show
          Emmanuel Lecharny added a comment - Please do not close issue you don't own, especially if the issue is still present !

            People

            • Assignee:
              Emmanuel Lecharny
              Reporter:
              Hans Lohmander
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development