[
https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13161738#comment-13161738
]
Dag H. Wanvik commented on DERBY-866:
-------------------------------------
> 2) This version of the spec phrases password procedure arguments as
> CLOBs in order to address the Java vulnerability described here:
>
> http://securesoftware.blogspot.com/2009/01/java-security-why-not-to-use-string.html
> An alternative approach would be to introduce a new Derby datatype
> corresponding to char[]. Other suggestions are welcome.
Btw, this article mentions not String objects are not necessarily
immutable (although the interened strings are):
http://directwebremoting.org/blog/joe/2005/05/26/java_lang_string_is_not_immutable.html
I checked that with our default server policy, this attack doesn't
work:
java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessDeclaredMembers)
***
lowercase
Good to know.
> Derby User Management Enhancements
> ----------------------------------
>
> Key: DERBY-866
> URL: https://issues.apache.org/jira/browse/DERBY-866
> Project: Derby
> Issue Type: Improvement
> Components: Services
> Affects Versions: 10.2.1.6
> Reporter: Francois Orsini
> Attachments: Derby_User_Enhancement.html,
> Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java,
> UserManagement.html, dummyCredentials.properties
>
>
> Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec
> attached to the JIRA).
> Abstract:
> This feature aims at improving the way BUILT-IN users are managed in Derby by
> providing a more intuitive and familiar DDL interface. Currently (in
> 10.1.2.1), Built-In users can be defined at the system and/or database level.
> Users created at the system level can be defined via JVM or/and Derby system
> properties in the derby.properties file. Built-in users created at the
> database level are defined via a call to a Derby system procedure
> (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property.
> Defining a user at the system level is very convenient and practical during
> the development phase (EOD) of an application - However, the user's password
> is not encrypted and consequently appears in clear in the derby.properties
> file. Hence, for an application going into production, whether it is embedded
> or not, it is preferable to create users at the database level where the
> password is encrypted.
> There is no real ANSI SQL standard for managing users in SQL but by providing
> a more intuitive and known interface, it will ease Built-In User management
> at the database level as well as Derby's adoption.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira