[
https://issues.apache.org/jira/browse/DERBY-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen resolved DERBY-5539.
---------------------------------------
Resolution: Fixed
Fix Version/s: 10.9.0.0
Issue & fix info: (was: Patch Available)
Committed revision 1292704.
Marking the issue as resolved since there's no more planned work.
> 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
> Fix For: 10.9.0.0
>
> Attachments: d5539-1a.diff, d5539-1b.diff, d5539-2a.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
