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


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

        

Reply via email to