Derby
  1. Derby
  2. DERBY-3272

BUILTIN authentication: Passwords stored in a database are not hashed if also defined as system property

    Details

    • Urgency:
      Normal
    • Issue & fix info:
      Known fix, Newcomer, Workaround attached
    • Bug behavior facts:
      Security

      Description

      Normally, passwords stored as database properties when using Derby's BUILTIN authentication provider are hashed using the well-known SHA-1 algorithm (although this is most likely not mentioned in the documentation). This makes it very hard for attackers to reconstruct the actual password even if they are able to obtain the hashed password value from the database.

      However, if credentials for the same user are also defined programmatically, for example on the command line, the password is not hashed before it is being stored in the database. This could lead to surprises if, for example, a user is using system properties during development, and decides to switch to database properties only before deployment, as recommended in the documentation [1].

      Workaround: Do not specify the same user credentials programmatically when setting credentials as database properties. For example, define a temporary user by using system properties when storing real user credentials in the database.

      [1]: http://db.apache.org/derby/docs/dev/devguide/tdevcsecure82556.html

      1. noPasswordHash.sql
        1 kB
        John H. Embretsen

        Issue Links

          Activity

          John H. Embretsen created issue -
          Hide
          John H. Embretsen added a comment -

          Attaching an SQL script which reproduces this bug. Run for example using:

          java -Dderby.user.admin=dummypassword -jar $DERBYJARS/derbyrun.jar ij noPasswordHash.sql

          Show
          John H. Embretsen added a comment - Attaching an SQL script which reproduces this bug. Run for example using: java -Dderby.user.admin=dummypassword -jar $DERBYJARS/derbyrun.jar ij noPasswordHash.sql
          John H. Embretsen made changes -
          Field Original Value New Value
          Attachment noPasswordHash.sql [ 12371524 ]
          Rick Hillegas made changes -
          Link This issue relates to DERBY-3271 [ DERBY-3271 ]
          Hide
          John H. Embretsen added a comment - - edited

          If you uncomment the additional "call" statements in the repro (enabling authentication), then run it once while specifying -Dderby.user.admin=dummypassword on the command line, you will not be able to run it successfully a second time if you remove the property from the command line when starting IJ. This is most likely the same observed behavior as reported in DERBY-3271.

          Show
          John H. Embretsen added a comment - - edited If you uncomment the additional "call" statements in the repro (enabling authentication), then run it once while specifying -Dderby.user.admin=dummypassword on the command line, you will not be able to run it successfully a second time if you remove the property from the command line when starting IJ. This is most likely the same observed behavior as reported in DERBY-3271 .
          Hide
          John H. Embretsen added a comment -

          The tuning guide says that a system-wide property set on the command line overrides the same property if set as a database property. Fair enough, since this allows you to override a previously set database property temporarily by setting the property on the command-line.

          However, it does not say what happens when you actually set a database property, and at the same time override the property with a system property. From what I can tell from using a debugger, it seems that:

          • when the SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY procedure is called/prepared, the doValidateApplyAndMap() method in o.a.d.iapi.services.property.PropertyValidation.java "applies" and "maps" the new property only if the same property is not also set in the JVM (SET_IN_JVM, line 73).
          • the hashing of the password occurs in the "map" method that is being called.
          • when the property is also set as a JVM property, "apply" and "map" is not called, but the property is set as a database property anyway.

          I am not sure what "apply" and "map" actually means (the javadoc for PropertySetCallback.map() says "Map a proposed new value for a property to an official value."), but intuitively I find it odd that the property is set in this case without being hashed ("mapped"). Stretching it, I may be able to see how someone could argue that this is not a bug, but in that case it should be made very clear in the manuals how this works.

          As indicated earlier, there are two major implications of this issue:

          1) Users may think the password is stored securely (hashed) in the database, but it is actually stored in cleartext.

          2) The current functionality may also lead to authentication failures later on if the property is no longer overridden in the JVM, since upon authentication the property from the database, which was stored in cleartext, is compared against a hashed password supplied by the user, as seen in DERBY-3271.

          Opinions are welcome. I hope we can get this cleaned up at some point not too far into the future...

          Show
          John H. Embretsen added a comment - The tuning guide says that a system-wide property set on the command line overrides the same property if set as a database property. Fair enough, since this allows you to override a previously set database property temporarily by setting the property on the command-line. However, it does not say what happens when you actually set a database property, and at the same time override the property with a system property. From what I can tell from using a debugger, it seems that: when the SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY procedure is called/prepared, the doValidateApplyAndMap() method in o.a.d.iapi.services.property.PropertyValidation.java "applies" and "maps" the new property only if the same property is not also set in the JVM (SET_IN_JVM, line 73). the hashing of the password occurs in the "map" method that is being called. when the property is also set as a JVM property, "apply" and "map" is not called, but the property is set as a database property anyway. I am not sure what "apply" and "map" actually means (the javadoc for PropertySetCallback.map() says "Map a proposed new value for a property to an official value."), but intuitively I find it odd that the property is set in this case without being hashed ("mapped"). Stretching it, I may be able to see how someone could argue that this is not a bug, but in that case it should be made very clear in the manuals how this works. As indicated earlier, there are two major implications of this issue: 1) Users may think the password is stored securely (hashed) in the database, but it is actually stored in cleartext. 2) The current functionality may also lead to authentication failures later on if the property is no longer overridden in the JVM, since upon authentication the property from the database, which was stored in cleartext, is compared against a hashed password supplied by the user, as seen in DERBY-3271 . Opinions are welcome. I hope we can get this cleaned up at some point not too far into the future...
          Hide
          Radim Kolar added a comment -

          I also bounced into this issue. Real fix should be to hash passwords stored in database no matter if they are set as system property or not.

          after removing following lines:

          if (PropertyUtil.whereSet(key, d) == PropertyUtil.SET_IN_JVM)
          continue;

          from o.a.d.iapi.services.property.PropertyValidation.java everything works fine.

          Show
          Radim Kolar added a comment - I also bounced into this issue. Real fix should be to hash passwords stored in database no matter if they are set as system property or not. after removing following lines: if (PropertyUtil.whereSet(key, d) == PropertyUtil.SET_IN_JVM) continue; from o.a.d.iapi.services.property.PropertyValidation.java everything works fine.
          Dag H. Wanvik made changes -
          Derby Categories [Security]
          Dag H. Wanvik made changes -
          Component/s Security [ 11411 ]
          Dag H. Wanvik made changes -
          Component/s Services [ 11415 ]
          Hide
          Kathey Marsden added a comment -

          Triaged for 10.5.2. Set Urgency to normal. Perhaps it should be upped to Urgent for 10.6. Set Known Fix and Newcomer assuming the suggested fix is the right one.

          Show
          Kathey Marsden added a comment - Triaged for 10.5.2. Set Urgency to normal. Perhaps it should be upped to Urgent for 10.6. Set Known Fix and Newcomer assuming the suggested fix is the right one.
          Kathey Marsden made changes -
          Urgency Normal
          Issue & fix info [Known fix, Newcomer, Workaround attached]
          Kathey Marsden made changes -
          Link This issue is duplicated by DERBY-3271 [ DERBY-3271 ]
          Kathey Marsden made changes -
          Labels derby_triage10_5_2
          Knut Anders Hatlen made changes -
          Link This issue is related to DERBY-5507 [ DERBY-5507 ]
          Hide
          Knut Anders Hatlen added a comment -

          This bug was fixed in 10.9.1.0 as part of DERBY-5507. Closing the issue.

          Show
          Knut Anders Hatlen added a comment - This bug was fixed in 10.9.1.0 as part of DERBY-5507 . Closing the issue.
          Knut Anders Hatlen made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Fix Version/s 10.9.1.0 [ 12316344 ]
          Resolution Fixed [ 1 ]
          Gavin made changes -
          Workflow jira [ 12419160 ] Default workflow, editable Closed status [ 12802094 ]
          Kathey Marsden made changes -
          Labels derby_triage10_5_2 derby_backport_reject_10_8 derby_triage10_5_2

            People

            • Assignee:
              Unassigned
              Reporter:
              John H. Embretsen
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development