Derby
  1. Derby
  2. DERBY-3271

Using BUILTIN authentication, I can't log in as database creator after storing credentials in the database.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 10.3.1.4
    • Fix Version/s: None
    • Component/s: JDBC, Services
    • Labels:
      None
    • Bug behavior facts:
      Security

      Description

      Using builtin authentication I am able to create a database and store credentials for 2 users: the original database creator and a second user. After that, I am able to reconnect as the second user but not as the original database creator. My test case follows.

      ------------------------------

      Here is my command for running ij with authentication turned on:

      java \
      -cp $CLASSPATH \
      -Dderby.stream.error.logSeverityLevel=0 \
      \
      -Dderby.connection.requireAuthentication=true \
      -Dderby.authentication.provider=BUILTIN \
      -Dderby.user.builtindba=dummypassword \
      \
      org.apache.derby.tools.ij myscript.sql

      Here is the first run of my script. This creates the database and stores credentials for 2 users, including the connected user:

      ij version 10.4
      ij> –
      -- First try to connect as builtindba.

      connect 'jdbc:derby:derby_builtin;create=true;user=builtindba;password=dummypassword';
      ij> –
      -- If I can't connect as builtindba, try connecting as fred.

      connect 'jdbc:derby:derby_builtin;create=true;user=fred;password=wilma';
      ERROR 08004: Connection authentication failure occurred. Reason: Invalid authentication..
      ij> –
      -- Store passwords in the database where they will be encrypted.

      call syscs_util.syscs_set_database_property( 'derby.user.builtindba', 'dummypassword' );
      0 rows inserted/updated/deleted
      ij> call syscs_util.syscs_set_database_property( 'derby.user.fred', 'wilma' );
      0 rows inserted/updated/deleted
      ij> values current_user;
      1
      --------------------------------------------------------------------------------------------------------------------------------
      BUILTINDBA

      1 row selected

      Here is the second run of my script. This fails to connect as the original user but succeeds as the other user:

      ij version 10.4
      ij> –
      -- First try to connect as builtindba.

      connect 'jdbc:derby:derby_builtin;create=true;user=builtindba;password=dummypassword';
      ERROR 08004: Connection authentication failure occurred. Reason: Invalid authentication..
      ij> –
      -- If I can't connect as builtindba, try connecting as fred.

      connect 'jdbc:derby:derby_builtin;create=true;user=fred;password=wilma';
      WARNING 01J01: Database 'derby_builtin' not created, connection made to existing database instead.
      ij> –
      -- Store passwords in the database where they will be encrypted.

      call syscs_util.syscs_set_database_property( 'derby.user.builtindba', 'dummypassword' );
      0 rows inserted/updated/deleted
      ij> call syscs_util.syscs_set_database_property( 'derby.user.fred', 'wilma' );
      0 rows inserted/updated/deleted
      ij> values current_user;
      1
      --------------------------------------------------------------------------------------------------------------------------------
      FRED

      1 row selected

      1. Derby3271Repro.java
        6 kB
        John H. Embretsen

        Issue Links

          Activity

          Hide
          John H. Embretsen added a comment -

          I doubt this is related to the fact that one of the users is the database owner: If I specify -Dderby.user.fred=wilma on the command line as well, fred is also denied access on the second run.

          However, I think there is a problem with the implementation of property precedence. According to the Tuning Guide, "system-wide properties set programmatically override database-wide properties and system-wide properties set in the derby.properties file" (where "programmatically" includes "on the command line"). (from http://db.apache.org/derby/docs/dev/tuning/ctunsetprop23308.html )

          When I run the attached repro (Derby3271Repro.java) with a debugger, I see that the class org.apache.derby.impl.jdbc.authentication.BasicAuthenticationServiceImpl compares a hashed ("encrypted") version of the passed in password against the password defined as a system property if the property also exists as a database property, so password comparison fails (hash(pwd) != pwd). This is in contrast to what the documentation says.

          See BasicAuthenticationServiceImpl.java, lines 194 ->.

          Instead, I think the implementation should hash the user-supplied password before comparison only if the property is set as a database property and it is not set as a system property. This way, cleartext will be compared to cleartext.

          Does this make sense?

          Show
          John H. Embretsen added a comment - I doubt this is related to the fact that one of the users is the database owner: If I specify -Dderby.user.fred=wilma on the command line as well, fred is also denied access on the second run. However, I think there is a problem with the implementation of property precedence. According to the Tuning Guide, "system-wide properties set programmatically override database-wide properties and system-wide properties set in the derby.properties file" (where "programmatically" includes "on the command line"). (from http://db.apache.org/derby/docs/dev/tuning/ctunsetprop23308.html ) When I run the attached repro (Derby3271Repro.java) with a debugger, I see that the class org.apache.derby.impl.jdbc.authentication.BasicAuthenticationServiceImpl compares a hashed ("encrypted") version of the passed in password against the password defined as a system property if the property also exists as a database property, so password comparison fails (hash(pwd) != pwd). This is in contrast to what the documentation says. See BasicAuthenticationServiceImpl.java, lines 194 ->. Instead, I think the implementation should hash the user-supplied password before comparison only if the property is set as a database property and it is not set as a system property. This way, cleartext will be compared to cleartext. Does this make sense?
          Hide
          John H. Embretsen added a comment -

          This may be related to DERBY-224, an issue which was closed as invalid based on (among other things) this statement

          • Users defined at the database level take precedence over the ones at system level

          This may be true with the current implementation, but it does not necessarily match the documentation (depending on how you define system level properties - programmatically or in a derby.properties file).

          Show
          John H. Embretsen added a comment - This may be related to DERBY-224 , an issue which was closed as invalid based on (among other things) this statement Users defined at the database level take precedence over the ones at system level This may be true with the current implementation, but it does not necessarily match the documentation (depending on how you define system level properties - programmatically or in a derby.properties file).
          Hide
          Rick Hillegas added a comment -

          Hi John.

          Thanks for running these experiments. It sounds as though you have uncovered a bug related to property precedence and the hashing of the password. When you store a password using SYSCS_SET_DATABASE_PROPERTY, what is actually stored is a hashed value. Your theory sounds plausible to me.

          However, there may be another bug in here. I see the original bug under the following circumstance:

          1) Remove the database.

          2) Run the script, specifying credentials for builtindba on the vm boot command. This creates a database and stores passwords for builtindba and fred.

          3) Then rerun the script without specifying credentials for anyone on the vm boot command. This fails to connect as builtindba but sucessfully connects as fred.

          Show
          Rick Hillegas added a comment - Hi John. Thanks for running these experiments. It sounds as though you have uncovered a bug related to property precedence and the hashing of the password. When you store a password using SYSCS_SET_DATABASE_PROPERTY, what is actually stored is a hashed value. Your theory sounds plausible to me. However, there may be another bug in here. I see the original bug under the following circumstance: 1) Remove the database. 2) Run the script, specifying credentials for builtindba on the vm boot command. This creates a database and stores passwords for builtindba and fred. 3) Then rerun the script without specifying credentials for anyone on the vm boot command. This fails to connect as builtindba but sucessfully connects as fred.
          Hide
          John H. Embretsen added a comment -

          I created a new issue, DERBY-3272, could this be what you are seeing?

          Details:
          If the password, when stored as a database property, is also defined on the command line, the password will be stored in cleartext in the database (a bug). Then, on the next connection when the supplied password is compared against the password in the database, Derby creates a hash from the supplied password and compares it to what's in the database. Obviously, if the database stores cleartext, the values won't match.

          Show
          John H. Embretsen added a comment - I created a new issue, DERBY-3272 , could this be what you are seeing? Details: If the password, when stored as a database property, is also defined on the command line, the password will be stored in cleartext in the database (a bug). Then, on the next connection when the supplied password is compared against the password in the database, Derby creates a hash from the supplied password and compares it to what's in the database. Obviously, if the database stores cleartext, the values won't match.
          Hide
          Rick Hillegas added a comment -

          Thanks for logging the new issue, John. I think that your description accounts for all of the symptoms which I am seeing.

          Show
          Rick Hillegas added a comment - Thanks for logging the new issue, John. I think that your description accounts for all of the symptoms which I am seeing.
          Hide
          Kathey Marsden added a comment -

          Comments indicate that this is a duplicate of DERBY-3272

          Show
          Kathey Marsden added a comment - Comments indicate that this is a duplicate of DERBY-3272
          Hide
          Kathey Marsden added a comment -

          Marked as duplicate of DERBY-3272

          Show
          Kathey Marsden added a comment - Marked as duplicate of DERBY-3272

            People

            • Assignee:
              Unassigned
              Reporter:
              Rick Hillegas
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development