Chris,
On 6.2.2014 15:28, Christopher Schultz wrote:
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.
Linux, I think, uses "$" as salt separator. I don't know about other
implementations. Maybe you could consider using "$" as separator users
are accustomed at?
Default salting is relevant only when storing password hash (e.g.
changing password), not when validating it, right? Validating part is
part of Realm. Realm checks for separator in the password hash. If the
separator exists, password is salted.
So, default salting and default salt length would be only important when
storing password hash. But that is not part of Tomcat's Realm
implementation. Or, am I missing something?
4. password-based key derivation functions (e.g. bcrypt, scrypt, pbkdf2)
This would also be trivial given such changes.
Great.
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?
TBH, I have no idea. It is just on my wishlist. At first thought every
Realm implementation would need to somehow inform Tomcat is what kind of
password protection does it use (none, hash, salted hash, pbkdf,
unknown), and Tomcat would act accordingly (log a warning message, if
needed).
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.
Absolutely.
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.
Well, Tomcat would start to *support* salts, and user must decide
whether to use it, and change the way password hashes are stored. That
is similar to adding new hash function, for instance.
-Ognjen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
