[
https://issues.apache.org/jira/browse/DERBY-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291909#comment-13291909
]
Rick Hillegas commented on DERBY-5622:
--------------------------------------
Thanks for the additional comments, Dag. I'm proposing that we introduce the
new procedure as a separate, orthogonal issue.
I agree that the bug still needs to be addressed. I'm convinced that there is
value in just changing the boot password without re-encrypting the data. Right
now, I'm considering two approaches to addressing this issue:
1) Save the real boot password somewhere at boot time and compare it to what is
passed into the password-changing procedure (currently
SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY). The advantage of this solution is that
it is airtight. The disadvantage is that a sensitive piece of information would
be maintained in memory somewhere, which seems like a security vulnerability to
me.
2) Continue to try to reconstruct the generated key from the boot password that
was passed to the password-changing procedure. Use this to create a new
CipherProvider. Then use the old CipherProvider to encrypt some long byte array
and decrypt the result with the new CipherProvider. If the result is the
original byte array, then the boot password was probably correct. This is not
airtight, but with a sufficiently long byte array the probability of data
corruption might be vanishingly small.
I would be interested in your thoughts. Thanks.
> 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
