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