db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.
Date Thu, 19 Jul 2012 18:57:37 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rick Hillegas resolved DERBY-5622.
----------------------------------

       Resolution: Fixed
    Fix Version/s: 10.10.0.0
                   10.9.1.1
                   10.8.2.3

Ported 1356749 from trunk to 10.9 at subversion revision 1363472.

Ported 1356749 from trunk to 10.8 at subversion revision 1363475.

Resolving this issue.

                
> 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
>             Fix For: 10.8.2.3, 10.9.1.1, 10.10.0.0
>
>         Attachments: derby-5622-01-aa-decryptEncryptedSample.diff, derby-5622-TT-fixWithTestScaffolding.diff,
derby-5622-instrumentation.diff, derby-5622-repro.sql, 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

        

Mime
View raw message