Details

    • Type: Bug
    • Status: Resolved
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 2.2.4
    • Fix Version/s: 2.2.5
    • Component/s: Security
    • Labels:
      None
    • Environment:

      Linux 2.6.
      Standalone Artifactory with Jetty (currently I am only running it locally for evaluation purposes).
      LDAP server is Sun Directory Server 5.2, aka SunONE LDAP.

      Description

      When using LDAP authentication, providing a blank password is treated as a successful login. The cause is that the back-end LDAP server treats a bind with an empty/blank password as an anonymous bind, and I suspect the LDAP code in artifactory simply looks for a successful bind. This probably only happens with certain LDAP server implementations, but SunONE LDAP (which we use at my site) does this.

      Supporting quote from http://www.ucalgary.ca/it/directories/identity/ldap

      WARNING: An attempt to bind with a blank password always succeeds because the LDAP protocol considers this to be an "anonymous" bind, even though a username is specified. Always check for a blank password before binding.

      This occurs both at the login screen and on the "Test LDAP Connection" page:

      • Test Username correct, Test password correct: "Successful connection"
      • Test Username correct, Test password wrong: "Authentication failed"
      • Test Username correct, password empty: "Successful connection" (bad!)
      • Test Username correct, password spaces only: "Successful connection" (bad!)
      • Test Username does not exist, Test password exists: "Authentication failed"
      • Test Username does not exist, Test password spaces only: "No such object" (bad, kind of)

      Obviously this is a bad situation because you can log in as anyone by providing a blank password on the login screen.

      I think this will only happen when using the "User DN Pattern", because using a "Manager DN" will first bind as the manager and then check the password. However I can't verify this at the moment because I don't have access to such a DN at my site.

      Suggested fix is to not make LDAP bind attempts with empty passwords, or passwords containing only spaces, and treat them as failed authentication attempts. Not sure if there is a legitimate requirement for logins with blank passwords, but if so maybe make it an option which is off by default.

        Attachments

          Issue Links

            Activity

            Hide
            cohen.tomer Tomer Cohen added a comment -

            A part of RFC 4153

            "5.1.2. Unauthenticated Authentication Mechanism of Simple Bind

            An LDAP client may use the unauthenticated authentication mechanism
            of the simple Bind method to establish an anonymous authorization
            state by sending a Bind request with a name value (a distinguished
            name in LDAP string form [RFC4514] of non-zero length) and specifying
            the simple authentication choice containing a password value of zero
            length.
            The distinguished name value provided by the client is intended to be
            used for trace (e.g., logging) purposes only. The value is not to be
            authenticated or otherwise validated (including verification that the
            DN refers to an existing directory object). The value is not to be
            used (directly or indirectly) for authorization purposes.

            Unauthenticated Bind operations can have significant security issues
            (see Section 6.3.1). In particular, users intending to perform
            Name/Password Authentication may inadvertently provide an empty
            password and thus cause poorly implemented clients to request
            Unauthenticated access. Clients SHOULD be implemented to require
            user selection of the Unauthenticated Authentication Mechanism by
            means other than user input of an empty password. Clients SHOULD
            disallow an empty password input to a Name/Password Authentication
            user interface. Additionally, Servers SHOULD by default fail
            Unauthenticated Bind requests with a resultCode of
            unwillingToPerform."

            Show
            cohen.tomer Tomer Cohen added a comment - A part of RFC 4153 "5.1.2. Unauthenticated Authentication Mechanism of Simple Bind An LDAP client may use the unauthenticated authentication mechanism of the simple Bind method to establish an anonymous authorization state by sending a Bind request with a name value (a distinguished name in LDAP string form [RFC4514] of non-zero length) and specifying the simple authentication choice containing a password value of zero length. The distinguished name value provided by the client is intended to be used for trace (e.g., logging) purposes only. The value is not to be authenticated or otherwise validated (including verification that the DN refers to an existing directory object). The value is not to be used (directly or indirectly) for authorization purposes. Unauthenticated Bind operations can have significant security issues (see Section 6.3.1). In particular, users intending to perform Name/Password Authentication may inadvertently provide an empty password and thus cause poorly implemented clients to request Unauthenticated access. Clients SHOULD be implemented to require user selection of the Unauthenticated Authentication Mechanism by means other than user input of an empty password. Clients SHOULD disallow an empty password input to a Name/Password Authentication user interface. Additionally, Servers SHOULD by default fail Unauthenticated Bind requests with a resultCode of unwillingToPerform ."

              People

              • Assignee:
                cohen.tomer Tomer Cohen
                Reporter:
                tcp Tim Peters
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: