db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5539) Harden password hashing in the builtin authentication service
Date Wed, 22 Feb 2012 12:53:48 GMT

     [ 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-2a.diff

There's one more thing I'd like to change before I mark this issue as resolved. The OWASP
page doesn't mention it explicitly, but the code example has a comment saying:

// TIME RESISTANT ATTACK (Even if the user does not exist the
// Computation time is equal to the time needed for a legitimate user

I think the point here is that we should always generate a hashed token, also if the user
does not exist, so that attackers cannot use the difference in computation time to determine
whether or not a user exists.

The attached patch (d5539-2a.diff) makes BasicAuthenticationServiceImpl.authenticateUser()
generate a hashed token based on the supplied credentials if it couldn't find a user with
the specified name at the database level. The token is thrown away once it's generated, since
its only purpose is to make the authentication failure as slow for non-existing users as it
is for existing users.

Without the patch, 10000 unsuccessful attempts to connect to a database using a non-existing
user name took 40 seconds in my environment, whereas 10000 unsuccessful connection attempts
with an existing user name took 9 seconds. With the patch, 10000 unsuccessful connection attempts
took 40 seconds in both scenarios.

All the regression tests ran cleanly with the patch.
> 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:
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>         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
> - 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


View raw message