tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Tomcat + j_security_check (JDBCRealm) + salt / jBCrypt
Date Mon, 27 Aug 2012 22:06:44 GMT
Salek,

On 8/20/12 3:31 PM, Salek Talangi wrote:
> Hi all,
> 
> I just started using Tomcat+j_security_check (JDBCRealm) for Form-based Webapp-Login.
> I read [1] that only a few standard (MD5, SHA-1, MD2?) java.security.MessageDigest methods
are supported, which isn't enough in times of (still) weak passwords and GPU brute force attacks
on DB-dumps.
> 
> What I'd like to know is if it is planned to do either of the
> following in the near future:
> 
> I) Adding a optional "salt" column that is used by j_security_check
> and adding support for SHA-2 (SHA-256, SHA-512)?

You can already use any message digest that is supported by your JVM.
For my JVM that I have in front me me, that list is:

MD2, MD5, SHA-1, SHA-256, SHA-384, SHA-256

If you add a provided like BouncyCastle, you may be able to get more
right out of the box.

As for the salt, there are no current BZ enhancements requesting such a
thing. I recently added a salt + iterations to my own DataSourceRealm
implementation (which is largely based upon the Tomcat DataSourceRealm)
and that could probably be contributed. I'm sure there will be enough
impedance that it wouldn't be completely trivial, but definitely doable.

> II) Integrating a pluggable digest system which allows the use of
> jBCrypt

Supporting separate password-obfuscation algorithms like bcrypt, scrypt,
etc. is less straightforward because the current code looks like this:

MessageDigest md = MessageDigest.getDigest(algorithm);
byte[] hashed = md.doFinal(password);

Being able to handle different non-MessageDigest APIs obviously makes
the code more complicated. We might be able to create a PasswordHasher
component or something like that which would know that "bcrypy",
"scrypt", etc. meant something special -- or could have implementation
classes registered for those names and fall-back on using MessageDigest
for other names (like MD5).

> At least the salt-part of "I" should be very easy to implement, most
> likely in org.apache.catalina.authenticator.FormAuthenticator?

No, you want that in RealmBase because the authentication actaully
happens in the Realm, not the Authenticator (which certainly is
confusing given the name of the component that *doesn't* do authentication).

Log an enhancement request for these issues (separately, please) in
Bugzilla.

-chris


Mime
View raw message