db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3272) BUILTIN authentication: Passwords stored in a database are not hashed if also defined as system property
Date Fri, 14 Dec 2007 13:47:43 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551800

John H. Embretsen commented on DERBY-3272:

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

> BUILTIN authentication: Passwords stored in a database are not hashed if also defined
as system property
> --------------------------------------------------------------------------------------------------------
>                 Key: DERBY-3272
>                 URL: https://issues.apache.org/jira/browse/DERBY-3272
>             Project: Derby
>          Issue Type: Bug
>          Components: Security
>    Affects Versions:
>         Environment: BUILTIN authentication enabled
>            Reporter: John H. Embretsen
>         Attachments: noPasswordHash.sql
> 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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message