You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "John H. Embretsen (JIRA)" <ji...@apache.org> on 2007/12/12 17:23:43 UTC
[jira] Created: (DERBY-3272) BUILTIN authentication: Passwords
stored in a database are not hashed if also defined as system property
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
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.
[jira] Commented: (DERBY-3272) BUILTIN authentication: Passwords
stored in a database are not hashed if also defined as system property
Posted by "John H. Embretsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551029 ]
John H. Embretsen commented on DERBY-3272:
------------------------------------------
If 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.
> 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.
[jira] Commented: (DERBY-3272) BUILTIN authentication: Passwords
stored in a database are not hashed if also defined as system property
Posted by "Radim Kolar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620992#action_12620992 ]
Radim Kolar commented on DERBY-3272:
------------------------------------
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.
> 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.
[jira] Updated: (DERBY-3272) BUILTIN authentication: Passwords
stored in a database are not hashed if also defined as system property
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-3272:
----------------------------------
Issue & fix info: [Known fix, Newcomer, Workaround attached]
Urgency: Normal
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.
> 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: Services
> 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.
[jira] Updated: (DERBY-3272) BUILTIN authentication: Passwords
stored in a database are not hashed if also defined as system property
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-3272:
---------------------------------
Component/s: Services
> 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: Services
> 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.
[jira] Commented: (DERBY-3272) BUILTIN authentication: Passwords
stored in a database are not hashed if also defined as system property
Posted by "John H. Embretsen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Issue Comment Edited: (DERBY-3272) BUILTIN authentication:
Passwords stored in a database are not hashed if also defined as system
property
Posted by "John H. Embretsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551029 ]
johnemb edited comment on DERBY-3272 at 12/12/07 8:51 AM:
--------------------------------------------------------------------
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.
was (Author: johnemb):
If 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.
> 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.
[jira] Updated: (DERBY-3272) BUILTIN authentication: Passwords
stored in a database are not hashed if also defined as system property
Posted by "John H. Embretsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John H. Embretsen updated DERBY-3272:
-------------------------------------
Attachment: noPasswordHash.sql
Attaching an SQL script which reproduces this bug. Run for example using:
java -Dderby.user.admin=dummypassword -jar $DERBYJARS/derbyrun.jar ij noPasswordHash.sql
> 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.