On 4.2.2014 21:29, "Gabriel E. Sánchez Martínez" wrote:
I've been tossing-around some upgrades in my mind for the realm
implementations that would allow for better pluggability for things like
this. Right now, the only way to implement, say, bcrypt, would be to
write your own Realm. That's silly: all you need to do is implement two
methods: mutatePassword() and verifyMutatedPassword().
That opens the door for all kinds of things like bcrypt/scrypt/etc. with
a trivial pluggable interface.
...
-chris
...
Bravo! I agree on a need for more pluggability. And I believe that out
of the box it should offer stronger protection. Ideally hashes designed
for password storage, but if not at least it should support salting.
IMO, it would be great if Tomcat could support:
1. plain text passwords
2. hashed passwords using crypto hash functions
3. option 2 with salt
4. password-based key derivation functions (e.g. bcrypt, scrypt, pbkdf2)
I also think that if the user selects anything other then option 4,
Tomcat should log a gentle warning during startup with suggestion that
there is a more secure solution for storing passwords.
Tomcat already suggests that APR is superior connector, why wouldn't it
also suggest what is the best practice for other things like passwords?
For option number 4, in order to avoid adding new dependecies to Tomcat,
it would be just fine to add step-by-step guide how to enable particular
KDF.
At the moment options 1 and 2 are supported. There is already some work
done to support options 3 and 4 on this thread, as well as on issues:
https://issues.apache.org/bugzilla/show_bug.cgi?id=53785
https://issues.apache.org/bugzilla/show_bug.cgi?id=51966
I am also willing to contribute some effort to implement those options.
-Ognjen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
