[
https://issues.apache.org/jira/browse/DERBY-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-5539:
--------------------------------------
Attachment: d5539-1b.diff
Thanks, Dag! I'm uploading an updated patch (d5539-1b.diff) which clarifies the
javadoc comment. Committed with revision 1221666. Further comments can be
addressed in followup patches.
> Nits: Do you need the upper bound in AuthenticationServiceBase#getIntProperty?
You're right, we don't, since both of the current callers pass in
Integer.MAX_VALUE. I guess it just felt more natural to specify the accepted
range rather than just the lower bound, especially since the method is a
general one. It shouldn't cause too much bloat, but I can remove that parameter
if you think that would be better.
(On a related note, I started wondering about what would happen if the salt
length was set so high that the token wouldn't fit in a varchar, and if we'd
need an upper bound. That turned out not to be an issue, as the db properties
conglomerate doesn't store the values in varchars. It stores them in UserType
columns. I tested with salt length 40000, which results in a token with more
than 80000 characters, and that worked fine.)
> Could you test with the salt in the upgrade test by reading the property
> first?
Yes and no. With non-zero length salts, the stored token will vary between test
runs, so in that case we'd need to duplicate the hashing algorithm in the test
in order to verify that we get the correct token. But the main purpose of the
test case is to verify that the token is stored in the expected format (for
which we just need to check the format identifier in the first four characters)
and that we're still able to connect after upgrade/downgrade, so we might also
run the test case with default salt length and disable the full checks of the
stored tokens. Those two alternatives should be more or less equivalent with
respect to what we want to test in this test.
> Harden password hashing in the builtin authentication service
> -------------------------------------------------------------
>
> Key: DERBY-5539
> URL: https://issues.apache.org/jira/browse/DERBY-5539
> Project: Derby
> Issue Type: Improvement
> Components: Services
> Affects Versions: 10.9.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Attachments: d5539-1a.diff, d5539-1b.diff
>
>
> The Open Web Application Security Project has some suggestions on how to make
> it harder for an attacker to crack hashed passwords:
> https://www.owasp.org/index.php/Hashing_Java
> The builtin authentication service doesn't follow all the suggestions. In
> particular, it doesn't add a random salt, and it only performs the hash
> operation once.
> I propose that we add two new properties that makes it possible to configure
> builtin to use a random salt and run multiple iterations of the hash
> operation:
> - derby.authentication.builtin.saltLength - the length of the random salt to
> add (in bytes)
> - derby.authentication.builtin.iterations - the number of times to perform
> the hash operation
> I'd also suggest that we set the defaults so that random salt and multiple
> iterations are used by default. The OWASP page mentions 64 bits of salt (8
> bytes) and a minimum of 1000 iterations. I consulted a security expert who
> thought that these recommendations sounded OK, but he believed the
> recommended salt length was likely to be revised and suggested 16 bytes
> instead. The only price we pay by going from 8 to 16 bytes, is that we'll
> need to store 8 bytes extra per user in the database, so I don't see any
> reason not to set the default for derby.authentication.builtin.saltLength as
> high as 16. Setting the default for derby.authentication.builtin.iterations
> to 1000 will make authentication of a user somewhat slower (which is the
> point, really), but experiments on my machine suggest that running our
> default hash function (SHA-256) 1000 times takes around 1 ms. Since
> authentication only happens when establishing a new connection to the
> database, that would be a negligible cost, I think.
> If saltLength is set to 0 and iterations is set to 1, the hashing will be
> done in the exact same way as in previous versions.
> Both of the properties should only be respected when the data dictionary
> version is 10.9 or higher, so that users in soft-upgraded databases can still
> log in after a downgrade.
--
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
