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 "Radim Kolar (JIRA)" <ji...@apache.org> on 2008/08/08 20:03:44 UTC

[jira] Commented: (DERBY-3272) BUILTIN authentication: Passwords stored in a database are not hashed if also defined as system property

    [ 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.