[
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
