Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 8 Jun 2012 18:23:24 +0000 (UTC)
From: "Dag H. Wanvik (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <707350110.53738.1339179804050.JavaMail.jiratomcat@issues-vm>
In-Reply-To: 
 <2060878091.52119.1329512697155.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Comment Edited] (DERBY-5622) Reduce the chance for hash
 collisions when checking bootPassword at boot time and when changing
 password.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Dag H. Wanvik edited comment on DERBY-5622 at 6/8/12 6:22 PM:
--------------------------------------------------------------

Note that the attribute called encryptedBootPassword is a bit of a misnomer: The value is actually the db encryption key encrypted using the boot password plus a hash of the db encryption key.

Btw, Rick, even if we introduce a new method for this, the issue would remain, unless we change the behavior to generate a new encryption key and re-encrypt. Is that what you are proposing?
                
      was (Author: dagw):
    Note that the attribute called encryptedBootPassword is a bit of a misnomer: The value is actually the db encryption key encrypted using the boot password plus a hash of the db encryption key.

Btw, Rick, even if we introduce a new method for this, the issue would remain, unless we change the behavior to generate a new encryption key and re-encrypt. IS that what you are proposing?
                  
> Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5622
>                 URL: https://issues.apache.org/jira/browse/DERBY-5622
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>            Reporter: Dag H. Wanvik
>         Attachments: derby-5622-instrumentation.diff, repro.sh
>
>
> There are two issues, already seen in DERBY-2687:
>    "the boot issue": there is a 1/2**16 chance that a wrong bootPassword will allow boot to proceed (but since its decoded key is wrong the boot will fail).
>    "the password change" issue: similarly, there is a chance that the wrong bootPassword will be accepted trying to change it via 
>     SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('bootPassword', ...) at least for algorithms that do not check IV (initialization vector) in addition to the
>     digest, e.g. "DES/ECB/NoPadding"
> The latter case may lead to data corruption, cf. DERBY-2687 discussion. I think the risk is fairly low, though: One would need to have execution permission to change the property if SQL authorization is used, and in most scenarios the supplied existing password would be correct. But since the results can be bad, it would be good to reduce or eliminate the risk.

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