Ognjen, On 2/5/14, 6:36 AM, Ognjen Blagojevic wrote: > 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
Already supported, of course. > 3. option 2 with salt Adding a salt would be trivial given the changes I have proposed. I'd love to enable salting by default when using a hash, but that may be surprising to some users. I suppose the salt could be separated from the salted-hashed-password by some obvious delimiter such as ":". See below for the "sync" problem. > 4. password-based key derivation functions (e.g. bcrypt, scrypt, pbkdf2) This would also be trivial given such changes. > 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. Well, using a PBKDF is best, but how can Tomcat know if you are using one? > Tomcat already suggests that APR is superior connector, why wouldn't it > also suggest what is the best practice for other things like passwords? There is another problem: the credential-verification system needs to be in sync with whatever system sets the passwords in the first place. For example, nobody uses Tomcat's Realms to actually change the password for their users: they do their own hashing, and write the new password to the database. If those processes are out of sync with each other, everything breaks. So, if Tomcat suddenly starts wanting to use salts, you won't get the benefit unless you have your own software actually using the salts. > 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. Cool. Introduction of a new interface shouldn't be a big deal. I'll try to slip it into Tomcat 8 before everyone gets concerned about API stability. -chris
signature.asc
Description: OpenPGP digital signature
