[
https://issues.apache.org/jira/browse/DERBY-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289721#comment-13289721
]
Dag H. Wanvik commented on DERBY-5622:
--------------------------------------
I think the problem can only occur when changing the bootpassword with
SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY. If one tries to change it at boot time,
the boot would fail since S-bogus couldn't decrypt the data and the boot will
fail with the same symptom as seen in DERBY-2687.
Apparently, when using SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY, the data isn't
being re-encrypted with a new secret key, and the old one gets lost
as explained above.
> 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
