Derby
  1. Derby
  2. DERBY-5648

Unclear password expiry warning when using separate credentials db

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.9.1.0
    • Fix Version/s: 10.9.1.0
    • Component/s: Services
    • Labels:
      None

      Description

      If you log on to a database (other than the credentials db) and your password is about to expire, you'll be advised to change your password using the SYSCS_UTIL.SYSCS_MODIFY_PASSWORD procedure. However, the warning message does not say you need to log on to the credentials db to change your password. This may lead the user to modify the password in the current database instead of the credentials database, thinking everything is well.

      ij(CONNECTION1)> connect 'jdbc:derby:otherdb;user=test;password=abc';
      WARNING 01J15: Your password will expire in 0 day(s). Please use the SYSCS_UTIL.SYSCS_MODIFY_PASSWORD procedure to change your password.
      ij(CONNECTION2)> CALL SYSCS_UTIL.SYSCS_MODIFY_PASSWORD('new-password');
      0 rows inserted/updated/deleted
      ij(CONNECTION2)> connect 'jdbc:derby:otherdb;user=test;password=new-password';
      ERROR 08004: Connection authentication failure occurred. Reason: Invalid authentication..

      Even though SYSCS_MODIFY_PASSWORD succeeds, the password has not been updated in the credentials db.

      1. derby-5648-01-ab-missingUser.diff
        11 kB
        Rick Hillegas
      2. derby-5648-01-aa-missingUser.diff
        10 kB
        Rick Hillegas

        Issue Links

          Activity

          Hide
          Rick Hillegas added a comment -

          Attaching derby-5648-01-ab-missingUser.diff. This patch removes a 10.9 upgrade test case which fails now that syscs_modify_password() raises the new error. Other than the upgrade failure, the tests ran cleanly for me. Committed at subversion revision 1300248.

          Touches the following additional file:

          M java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_9.java

          Show
          Rick Hillegas added a comment - Attaching derby-5648-01-ab-missingUser.diff. This patch removes a 10.9 upgrade test case which fails now that syscs_modify_password() raises the new error. Other than the upgrade failure, the tests ran cleanly for me. Committed at subversion revision 1300248. Touches the following additional file: M java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_9.java
          Hide
          Rick Hillegas added a comment -

          Attaching derby-5648-01-aa-missingUser.diff. This patch adds the database name to the password expiration messages. This patch also raises an error if you try to drop a user who doesn't exist or if you try to change the password of a missing user. I am running regression tests now.

          Touches the following files:

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

          M java/engine/org/apache/derby/iapi/error/SQLWarningFactory.java
          M java/engine/org/apache/derby/impl/jdbc/authentication/NativeAuthenticationServiceImpl.java
          M java/engine/org/apache/derby/loc/messages.xml
          M java/shared/org/apache/derby/shared/common/reference/SQLState.java

          New message and 2 changed messages. Added a factory method for 2-arg warnings.

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

          M java/engine/org/apache/derby/catalog/SystemProcedures.java

          Checks for whether user exists.

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

          M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthProcs.java

          Test cases.

          Show
          Rick Hillegas added a comment - Attaching derby-5648-01-aa-missingUser.diff. This patch adds the database name to the password expiration messages. This patch also raises an error if you try to drop a user who doesn't exist or if you try to change the password of a missing user. I am running regression tests now. Touches the following files: ------------ M java/engine/org/apache/derby/iapi/error/SQLWarningFactory.java M java/engine/org/apache/derby/impl/jdbc/authentication/NativeAuthenticationServiceImpl.java M java/engine/org/apache/derby/loc/messages.xml M java/shared/org/apache/derby/shared/common/reference/SQLState.java New message and 2 changed messages. Added a factory method for 2-arg warnings. ------------ M java/engine/org/apache/derby/catalog/SystemProcedures.java Checks for whether user exists. ------------ M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthProcs.java Test cases.
          Hide
          Knut Anders Hatlen added a comment -

          I agree that there's no strong reason to disallow SYSCS_MODIFY_PASSWORD completely in databases that doesn't use NATIVE::LOCAL.

          I think SYSCS_MODIFY_PASSWORD, SYSCS_RESET_PASSWORD and SYSCS_DROP_USER should fail if the user doesn't exist locally. It is a valid concern that a non-DBO user can use this to fish user names. However, that non-DBO user must be granted some admin rights by the DBO before, so it must be a trusted user in the first place. Also, someone with those rights has a much easier way to probe the user database: reset the password of a user account and then log on using the fresh credentials.

          Show
          Knut Anders Hatlen added a comment - I agree that there's no strong reason to disallow SYSCS_MODIFY_PASSWORD completely in databases that doesn't use NATIVE::LOCAL. I think SYSCS_MODIFY_PASSWORD, SYSCS_RESET_PASSWORD and SYSCS_DROP_USER should fail if the user doesn't exist locally. It is a valid concern that a non-DBO user can use this to fish user names. However, that non-DBO user must be granted some admin rights by the DBO before, so it must be a trusted user in the first place. Also, someone with those rights has a much easier way to probe the user database: reset the password of a user account and then log on using the fresh credentials.
          Hide
          Rick Hillegas added a comment -

          Thanks for the additional experiments, Knut.

          > Another question is whether there should have been an error when calling SYSCS_MODIFY_PASSWORD on a database that's not a credentials database. But I suppose that must be allowed so that the password of the DBO can be set before NATIVE is enabled?

          I think that the use-case is obscure: changing a password which you just set. However, I don't see a strong reason to forbid this.

          > Maybe SYSCS_MODIFY_PASSWORD (and SYSCS_RESET_PASSWORD) should fail, though, if there is no entry for the specified user in the local SYS.SYSUSERS table?

          And SYSCS_DROP_USER as well? The use-case for allowing these procedures to be called on non-existent users is obscure: It would involve delegating some but not all user-maintenance chores to an assistant. The assistant would be allowed to change the passwords of known users but would be prevented from using these procedures to fish for additional user names.

          The use-case for disallowing these procedures on non-existent users seems more important to me: alerting the DBO to the fact that she has mis-spelled a user name.

          Further thoughts?

          Thanks,
          -Rick

          Show
          Rick Hillegas added a comment - Thanks for the additional experiments, Knut. > Another question is whether there should have been an error when calling SYSCS_MODIFY_PASSWORD on a database that's not a credentials database. But I suppose that must be allowed so that the password of the DBO can be set before NATIVE is enabled? I think that the use-case is obscure: changing a password which you just set. However, I don't see a strong reason to forbid this. > Maybe SYSCS_MODIFY_PASSWORD (and SYSCS_RESET_PASSWORD) should fail, though, if there is no entry for the specified user in the local SYS.SYSUSERS table? And SYSCS_DROP_USER as well? The use-case for allowing these procedures to be called on non-existent users is obscure: It would involve delegating some but not all user-maintenance chores to an assistant. The assistant would be allowed to change the passwords of known users but would be prevented from using these procedures to fish for additional user names. The use-case for disallowing these procedures on non-existent users seems more important to me: alerting the DBO to the fact that she has mis-spelled a user name. Further thoughts? Thanks, -Rick
          Hide
          Knut Anders Hatlen added a comment -

          Option 2 sounds fine to me.

          Another question is whether there should have been an error when calling SYSCS_MODIFY_PASSWORD on a database that's not a credentials database. But I suppose that must be allowed so that the password of the DBO can be set before NATIVE is enabled? Maybe SYSCS_MODIFY_PASSWORD (and SYSCS_RESET_PASSWORD) should fail, though, if there is no entry for the specified user in the local SYS.SYSUSERS table?

          Show
          Knut Anders Hatlen added a comment - Option 2 sounds fine to me. Another question is whether there should have been an error when calling SYSCS_MODIFY_PASSWORD on a database that's not a credentials database. But I suppose that must be allowed so that the password of the DBO can be set before NATIVE is enabled? Maybe SYSCS_MODIFY_PASSWORD (and SYSCS_RESET_PASSWORD) should fail, though, if there is no entry for the specified user in the local SYS.SYSUSERS table?
          Hide
          Rick Hillegas added a comment -

          Thanks for logging this issue Knut. Here are some options for clarifying this error situation:

          1) The error message could contain the name of the database whose credentials are expiring. If the warning is raised because credentials are expiring for a system-wide operation (like engine shutdown), then the name of the system-wide credentials db will be revealed. I don't know if that is a problem but I suppose someone might consider that to be a security risk.

          2) We could use different error text depending on whether the credentials are expiring in a system-wide credentials db or in the local db. Something like:

          "Your password will expire in 0 day(s). Please use the SYSCS_UTIL.SYSCS_MODIFY_PASSWORD procedure to change your password in the system-wide credentials database."

          vs.

          "Your password will expire in 0 day(s). Please use the SYSCS_UTIL.SYSCS_MODIFY_PASSWORD procedure to change your password in this database."

          Thanks,
          -Rick

          Show
          Rick Hillegas added a comment - Thanks for logging this issue Knut. Here are some options for clarifying this error situation: 1) The error message could contain the name of the database whose credentials are expiring. If the warning is raised because credentials are expiring for a system-wide operation (like engine shutdown), then the name of the system-wide credentials db will be revealed. I don't know if that is a problem but I suppose someone might consider that to be a security risk. 2) We could use different error text depending on whether the credentials are expiring in a system-wide credentials db or in the local db. Something like: "Your password will expire in 0 day(s). Please use the SYSCS_UTIL.SYSCS_MODIFY_PASSWORD procedure to change your password in the system-wide credentials database." vs. "Your password will expire in 0 day(s). Please use the SYSCS_UTIL.SYSCS_MODIFY_PASSWORD procedure to change your password in this database." Thanks, -Rick

            People

            • Assignee:
              Rick Hillegas
              Reporter:
              Knut Anders Hatlen
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development