[jira] [Commented] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.
[
https://issues.apache.org/jira/browse/DERBY-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13405983#comment-13405983
]
Rick Hillegas commented on DERBY-5622:
--
Thanks for verifying the patch, Dag. Committed
derby-5622-01-aa-decryptEncryptedSample.diff at subversion revision 1356749.
> 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-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
[jira] [Commented] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.
[
https://issues.apache.org/jira/browse/DERBY-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13405903#comment-13405903
]
Dag H. Wanvik commented on DERBY-5622:
--
I looked at the patch and verified that the second line of defense here kicks
in if the first one is disabled as in your instrumented patch version.
Patch looks good, +1 .
Nits: some too long lines. One new line has a TAB: { throw
StandardException.newException(SQLState.WRONG_BOOT_PASSWORD); }
On that note, I'd prefer a newline after the "{" starting the explicit block.
> 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-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
[jira] [Commented] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.
[
https://issues.apache.org/jira/browse/DERBY-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294026#comment-13294026
]
Dag H. Wanvik commented on DERBY-5622:
--
Souns like a good approach, Rick, thanks. Like you, I am at a loss as far as
computing the total collision probability here, but your approach would seem to
help. I'll have a look at the detailed patch tomorrow.
I think I'd pass over any special bypass password, I'm happy with manual
inspection and testing here.
> 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-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
[jira] [Commented] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.
[
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
[jira] [Commented] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.
[
https://issues.apache.org/jira/browse/DERBY-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291898#comment-13291898
]
Dag H. Wanvik commented on DERBY-5622:
--
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
[jira] [Commented] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.
[
https://issues.apache.org/jira/browse/DERBY-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291866#comment-13291866
]
Rick Hillegas commented on DERBY-5622:
--
Hi Kim. Yes, I think it's worth clarifying the documentation. 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
[jira] [Commented] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.
[
https://issues.apache.org/jira/browse/DERBY-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291852#comment-13291852
]
Kim Haase commented on DERBY-5622:
--
You explain this with remarkable clarity, Rick -- and I don't think we ever
document clearly that using bootPassword is incompatible with using
encryptionKey. Shall I file a doc issue on this?
> 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
[jira] [Commented] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.
[
https://issues.apache.org/jira/browse/DERBY-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291838#comment-13291838
]
Rick Hillegas commented on DERBY-5622:
--
Thanks for the repro and the additional analysis, Dag. Here are some more
observations:
1) When you create an encrypted database, you specify either an explicit
encryption key or a boot password. If you specify a boot password, then Derby
generates an encryption key for you. You can't go back and forth between these
techniques. Once you specify a boot password, you can't try to figure out the
generated encryption key and boot the database using the encryption key.
Similarly, if you create the database with an explicit encryption key, you
can't try to introduce a boot password later on.
This is because Derby stores different verification metadata for the two
techniques. The verification metadata is used to catch bad boot passwords and
encryption keys before actually trying to decrypt the conglomerates. If Derby
can catch a bad boot password or encryption key before trying to decrypt the
conglomerates, then Derby can raise an intelligible error message.
If the database was created with a boot password, then Derby expects to find an
encryptedBootPassword attribute in service.properties. The value of this
attribute includes a digest used at boot time to verify the boot password
before trying to decrypt the conglomerates.
In contrast, if the database was created with an explicit encryption key, then
Derby generates a verifyKey.dat file next to service.properties. The contents
of verifyKey.dat are used at boot time to verify the encryption key before
trying to decrypt the conglomerates.
If you try to switch your encryption technique later on, Derby will fail to
boot because it will not find the verification metadata needed by the other
technique.
2) If you change the boot password using boot attributes, this generates a new
encryption key and re-encrypts the data.
3) If you change the boot password using
SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY, then a new encryption key is NOT
generated and the data is NOT re-encrypted.
4) Using SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY to change the boot password
strikes me as a little weird. The usage, however, goes back a long way, at
least as far back as Cloudscape 3.5. SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY was
originally designed to store Derby properties in the property conglomerate. The
boot password is not a property. It is a connection URL attribute. Furthermore,
the associated, generated encryption key is not stored in the properties
conglomerate. Instead, it is stored in service.properties. I don't think that
we should be manipulating the contents of service.properties with a procedure
which was designed to manage the property conglomerate. I support Knut's
suggestion on DERBY-4328 that we should introduce a new
SYSCS_UTIL.SYSCS_CHANGE_BOOT_PASSWORD procedure for changing the boot password
on the fly. I would support deprecating the use of
SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY to change the boot password; we could
raise an error telling users to use SYSCS_UTIL.SYSCS_CHANGE_BOOT_PASSWORD
instead. To mitigate the backward compatibility problems, we could phase in
this change over the course of a couple releases, warning people in 10.10 that
the old usage will be deprecated in 10.11.
> 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
[jira] [Commented] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.
[
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
[jira] [Commented] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.
[
https://issues.apache.org/jira/browse/DERBY-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289540#comment-13289540
]
Dag H. Wanvik commented on DERBY-5622:
--
Given an encrypted secret key S, which is stored in service.properties after
having been encrypted with the boot password BO, we have stored
S' = encrypt(S, BO)
The payload data D exists encrypted using S:
D' = encrypt(D, S)
so inverse, when we boot up again:
Using BO we do
S = decrypt(S', BO)
check digest(S) against stored digest, and get at the data:
D = decrypt(D', S).
Now, when we try to change the boot password in the pathological case, we do
this (using a bogus old boot password):
S-bogus = decrypt(S', B-bogus)
next, the check of S-bogus against digest and IV (initialization vector) would
normally fail it, but it could happen that it was erroneously accepted. The
what happen is we store using the new boot password (BN) onto
service.properties:
S-bogus' = encrypt(S-bogus, BN)
Meanwhile, the data is still encrypted with S; we don't reencrypt everything
after changing the boot password.
Next time we boot up again we do:
S-bogus = decrypt(S-bogus', BN)
which works nicely and passes the digest since we use the correct new boot
password, BN.
Now, trying to get the data:
decrypt(D', S-bogus)
will yield garbage, since we'd need to use S to get the correct data out.
So, to demonstrate this, I think you'll need to use a bogus key, make it pass
the digest and IV check using instrumentation of sorts, then shutdown, and
reboot to see if your data makes sense. They shouldn't.
> 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
>
> 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
[jira] [Commented] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.
[
https://issues.apache.org/jira/browse/DERBY-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289488#comment-13289488
]
Rick Hillegas commented on DERBY-5622:
--
Thanks, Dag. The discussion on that issue suggests that there is a way to
change the boot password so that the system becomes unbootable. That may be the
data corruption case you indicate. My simple attempts to script that problem
are not succeeding. I have tried commenting out the digest verification. That
causes the ClassNotFoundException when I try to give a bad boot password, but I
have not succeeded in creating an unbootable database.
Can you help me understand how to script the data corruption? Instructions
which describe how to fake a digest collision by instrumenting the engine are
fine, I just need to be able to arrive at an unbootable database. 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
>
> 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
[jira] [Commented] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.
[
https://issues.apache.org/jira/browse/DERBY-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1328#comment-1328
]
Dag H. Wanvik commented on DERBY-5622:
--
Please see discussion here:
https://issues.apache.org/jira/browse/DERBY-2687?focusedCommentId=13209225&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13209225
> 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
>
> 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
[jira] [Commented] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.
[
https://issues.apache.org/jira/browse/DERBY-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288847#comment-13288847
]
Rick Hillegas commented on DERBY-5622:
--
I am trying to figure out the data corruption entailed here. I can see a code
path by which supplying a wrong boot password can stumble forward to die on a
ClassNotFoundException. But after that, the correct boot password still boots
the database. Can you help me understand how to trigger a data corruption?
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
>
> 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
