Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Tue, 20 Dec 2011 22:31:30 +0000 (UTC)
From: "Dag H. Wanvik (Commented) (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <1532807048.32833.1324420290803.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1404107648.15069.1323946830914.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (DERBY-5539) Harden password hashing in the
 builtin authentication service
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DERBY-5539?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1317=
3570#comment-13173570 ]=20

Dag H. Wanvik commented on DERBY-5539:
--------------------------------------

Thanks, Knut. I read through the patch, and it looks good to me. +1

Nits: Do you need the upper bound in AuthenticationServiceBase#getIntProper=
ty?=20
The Javadoc for Changes10_9#testBuiltinAuthenticationWithConfigurableHash i=
s a little ambiguous in its use of "only".
Could you test with the salt in the upgrade test by reading the property fi=
rst?
               =20
> 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
>
>
> 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 op=
eration once.
> I propose that we add two new properties that makes it possible to config=
ure builtin to use a random salt and run multiple iterations of the hash op=
eration:
> - derby.authentication.builtin.saltLength - the length of the random salt=
 to add (in bytes)
> - derby.authentication.builtin.iterations - the number of times to perfor=
m the hash operation
> I'd also suggest that we set the defaults so that random salt and multipl=
e 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 wh=
o thought that these recommendations sounded OK, but he believed the recomm=
ended 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 st=
ore 8 bytes extra per user in the database, so I don't see any reason not t=
o set the default for derby.authentication.builtin.saltLength as high as 16=
. Setting the default for derby.authentication.builtin.iterations to 1000 w=
ill make authentication of a user somewhat slower (which is the point, real=
ly), but experiments on my machine suggest that running our default hash fu=
nction (SHA-256) 1000 times takes around 1 ms. Since authentication only ha=
ppens when establishing a new connection to the database, that would be a n=
egligible 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 sti=
ll log in after a downgrade.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira