Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 82464 invoked from network); 19 Apr 2010 22:28:12 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 19 Apr 2010 22:28:12 -0000 Received: (qmail 95327 invoked by uid 500); 19 Apr 2010 22:28:11 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 95304 invoked by uid 500); 19 Apr 2010 22:28:11 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 95297 invoked by uid 99); 19 Apr 2010 22:28:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Apr 2010 22:28:11 +0000 X-ASF-Spam-Status: No, hits=-1314.0 required=10.0 tests=ALL_TRUSTED,AWL X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Apr 2010 22:28:10 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o3JMRojo005682 for ; Mon, 19 Apr 2010 18:27:50 -0400 (EDT) Message-ID: <19985060.22491271716070392.JavaMail.jira@thor> Date: Mon, 19 Apr 2010 18:27:50 -0400 (EDT) From: "Knut Anders Hatlen (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-4579) Document the configurable hash authentication scheme In-Reply-To: <756851717.226261268398587316.JavaMail.jira@brutus.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/DERBY-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858706#action_12858706 ] Knut Anders Hatlen commented on DERBY-4579: ------------------------------------------- One more thing. After this issue was filed, the new authentication mechanism has been made the default for BUILTIN in new databases. At database creation time, the property will be initialized to SHA-256 (or under certain conditions SHA-1 because of DERBY-4602). We may want to state that in the documentation for the property. For example: "In a newly created database, the value of this property will be either SHA-256, if it is available on the platform, or SHA-1 otherwise." > 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: 10.6.0.0 > 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 property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.