[
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 future...
> 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: 10.3.2.1
> 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.
