db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kim Haase (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4579) Document the configurable hash authentication scheme
Date Mon, 19 Apr 2010 20:10:55 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858661#action_12858661

Kim Haase commented on DERBY-4579:

I've run into a couple of questions working on this --

Reference topic:

For dynamic properties, we say either

Dynamic; the change takes effect immediately.


Dynamic. Current connection is not affected, but all future connections
are affected. 

Which is the case for this property? I'm guessing it takes effect immediately, but I want
to make sure.

Admin Guide topic:

You suggest saying, "Strong password substitution can only be used with Derby's NONE and BUILTIN
authentication schemes." I'm not aware of a NONE scheme; for the derby.authentication.provider
property the possibilities are LDAP, BUILTIN, and a Java class name, which I thought also
indicated the use of an external authentication scheme. So is it only BUILTIN that you can
use strong password substitution with?

Thanks for any help.

> Document the configurable hash authentication scheme
> ----------------------------------------------------
>                 Key: DERBY-4579
>                 URL: https://issues.apache.org/jira/browse/DERBY-4579
>             Project: Derby
>          Issue Type: Improvement
>          Components: Documentation
>    Affects Versions:
>            Reporter: Knut Anders Hatlen
>            Assignee: Kim Haase
> DERBY-4483 adds the ability to configure which message digest algorithm to use to protect
the passwords that are stored in the database when using BUILTIN authentication.
> I think these changes are required:
> * Reference manual: Document the new database property derby.authentication.builtin.algorithm.
It's a dynamic property that can be set either on database level or on system level. Its value
is the name of a message digest algorithm available from one of the Java Cryptography Extension
providers registered in the JVM. Example values: MD5, SHA-256, SHA-512. The specified algorithm
will be applied on the concatenation of the user name and the password before it's stored
in the database. If the property is NULL or the empty string, the old algorithm (SHA-1 on
the password only) is applied instead.
> * Developer's guide: Mention the property in "List of user authentication properties"
> * Server and admin guide: In the table in section "Network client security", mention
that strong password substitution cannot be used to connect as a user whose password has been
stored with the new scheme. I'd suggest changing the following sentence:
>     Strong password substitution cannot be used with external Derby authentication schemes
(for example, LDAP).
> And replacing it with something like:
>     Strong password substitution can only be used with Derby's NONE and BUILTIN authentication
schemes. Also, for the BUILTIN scheme, it does not work for database-level users whose password
has been protected by a custom message digest algorithm specified by the derby.authentication.builtin.algorithm

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message