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
signature.asc
Description: OpenPGP digital signature
