tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ognjen Blagojevic <>
Subject Re: support for salted passwords
Date Sat, 08 Feb 2014 01:34:43 GMT

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.


>> 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 

>> 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.

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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message