You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Gabriel E. Sánchez Martínez" <ga...@gmail.com> on 2014/02/02 08:23:35 UTC
support for salted passwords
Hi developers,
I am very new to Tomcat but am already getting my feet wet with a web
application. A requirement for this application is form-based password
authentication, and I would like to store passwords in a database using
salted SHA-512 digests, recognizing that this is not state-of-the-art
password protection, but it is a more secure method than unsalted
digests in the event that the password table is compromised.
I saw that Tomcat doesn't support this out of the box, so I am wondering
if there is any interest in changing that. I wrote a custom Realm by
extending DataSourceRealm and overriding the few necessary methods.
This realm, which I've called SaltedDataSourceRealm, reads three
database columns (username, salt, password). It doesn't assume a
fixed-length salt, and it works with any supported digest algorithms.
It took me quite a while to figure everything out because the
documentation I found online isn't clear enough to a beginner, and some
forum posts refer to very old versions of Tomcat. I would be willing to
contribute an example of how to implement this custom realm to the
Tomcat documentation if there is interest.
Anyway, I tested the custom realm and it seems to be working as
intended. I went ahead and checked out the Tomcat 8 code and wrote the
class where it would go, and I am attaching the java file of that class
in case there is interest in considering an implementation like it in
future versions of Tomcat. (I've hard-coded the length of the salt, but
that should be changed to make it an argument of the XML file.)
After working a bit with the realms code I get the impression that it
could be cleaned up a bit. I think it would be good to move several
methods away from RealmBase so that no code there implements any
specific authentication logic or makes assumptions about
authentication. And I think it would be good for users to have the
option of using salts with the other password-based realms too. I'm not
sure that I have the experience required to do those changes, and I
certainly won't work on it without first hearing back from you.
This is my first message to the Tomcat developer community. All your
comments will be appreciated.
Regards,
Gabriel
Re: Re: support for salted passwords
Posted by Gabriel Sánchez Martínez <ga...@gmail.com>.
On 02/02/2014 02:51 AM, Nick Williams wrote:
> On Feb 2, 2014, at 1:23 AM, Gabriel E. Sánchez Martínez wrote:
>
>> Hi developers,
>>
>> I am very new to Tomcat but am already getting my feet wet with a web application. A requirement for this application is form-based password authentication, and I would like to store passwords in a database using salted SHA-512 digests
> I can't speak to most of this email, but don't do this. SHA-x is a *fast* hashing algorithm. It's not designed for passwords. The problem with fast hashing algorithms is that they are *very* susceptible to rainbow table attacks. Modern password-hacking systems with 24 GPUs can calculate billions of MD5 and SHA-x hash attacks per second.
>
> I strongly recommend you use a *slow* hashing algorithm such as bcrypt, which is designed specifically for hashing passwords. These algorithms use more than just CPU/GPU operations (such as memory). Password hacking systems can only calculate thousands of these per second instead of millions. It's much better protection in case your password database is ever stolen.
Thanks Nick. I will look into the options available for digest
algorithms. The code I attached works with any digest algorithm,
though. So I think (but do tell me if I am missing something) that the
question of whether there is interest to include a realm that supports
salted passwords still stands. Or more generally, it seems that the
realms that ship with Tomcat (specifically the ones based on password
storage) provide weak security in the event of a compromised password
table, which suggests two things. First, the documentation should be
improved so that newcomers (like me) better understand the risks
associated with using the standard realms, and they are better placed to
implement more secure realms. Second, Tomcat should ship with a more
secure password storage realm options so that newcomers get better
security out of the box. The defaults should be strong salted digests,
not cleartext or unsalted digests. Do people agree?
>
>> , recognizing that this is not state-of-the-art password protection, but it is a more secure method than unsalted digests in the event that the password table is compromised.
>>
>> <snip />
> Nick
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Re: support for salted passwords
Posted by Gabriel Sánchez Martínez <ga...@gmail.com>.
On 02/05/2014 05:12 PM, Christopher Schultz wrote:
> Gabriel,
>
> On 2/4/14, 3:29 PM, "Gabriel E. Sánchez Martínez" wrote:
>> On 02/04/2014 12:20 PM, Christopher Schultz wrote:
>>> Nick,
>>>
>>> On 2/2/14, 2:51 AM, Nick Williams wrote:
>>>> On Feb 2, 2014, at 1:23 AM, Gabriel E. Sánchez Martínez wrote:
>>>>> I am very new to Tomcat but am already getting my feet wet with a
>>>>> web application. A requirement for this application is form-based
>>>>> password authentication, and I would like to store passwords in a
>>>>> database using salted SHA-512 digests
>>>> I can't speak to most of this email, but don't do this. SHA-x is a
>>>> *fast* hashing algorithm. It's not designed for passwords. The
>>>> problem with fast hashing algorithms is that they are *very*
>>>> susceptible to rainbow table attacks. Modern password-hacking systems
>>>> with 24 GPUs can calculate billions of MD5 and SHA-x hash attacks per
>>>> second.
>>>>
>>>> I strongly recommend you use a *slow* hashing algorithm such as
>>>> bcrypt, which is designed specifically for hashing passwords. These
>>>> algorithms use more than just CPU/GPU operations (such as memory).
>>>> Password hacking systems can only calculate thousands of these per
>>>> second instead of millions. It's much better protection in case your
>>>> password database is ever stolen.
>>> While you are completely correct in your assessment (crypto hashes don't
>>> make good password hashes), the fact that Tomcat supports only the
>>> former is a somewhat tacit affirmation that simply using crypto hashing
>>> for passwords is good security.
>>>
>>> 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.
>>>
>>> Since it sounds like there's a bit of appetite for this, I may spend
>>> some more time on this (that is, some at all).
>>>
>>> -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.
> Well, out of the box would require two things: salting and iterating.
> Password-hashing algorithms are better than just adding salt and
> stirring SHD-512 or whatever.
Agreed, although even that would be a significant (and low effort) improvement over what we have now. So I would still welcome it, especially if it is the only option for out of the box.
>
> I'd love to be able to directly-support things like bcrypt and scrypt,
> but I'm not sure about their licensing and adding an external dependency
> isn't a great idea.
I share your concerns, but if there might be open source implementations. For example PBKDF2 is included in javax, and if that is still considered a dependency, there are plenty of open source implementations of it that we should be allowed to copy.
> I think the best we can hope for would be to add
> support at the code level for pluggable interfaces, and then put some
> samples on the Wiki for how to write a wrapper around something specific
> like bcrypt.
I support this idea, and perhaps the existing realms should all be made to use the proposed pluggable interface too. But I insist that if possible we should also have Tomcat offer a decent option to users without much resources or know-how or even patience to read the docs... Users should be able for example to configure PBKDF2 without having to implement their own code. After all, writing good security code is not trivial and should not be reinvented. It is too easy to innocently introduce vulnerabilities. So I'd like to see something better than what we have now ship with standard Tomcat, perhaps implemented using your pluggable interface idea. Tomcat is behind its peers in this regard. What do you think?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: support for salted passwords
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Gabriel,
On 2/4/14, 3:29 PM, "Gabriel E. Sánchez Martínez" wrote:
>
> On 02/04/2014 12:20 PM, Christopher Schultz wrote:
>> Nick,
>>
>> On 2/2/14, 2:51 AM, Nick Williams wrote:
>>> On Feb 2, 2014, at 1:23 AM, Gabriel E. Sánchez Martínez wrote:
>>>> I am very new to Tomcat but am already getting my feet wet with a
>>>> web application. A requirement for this application is form-based
>>>> password authentication, and I would like to store passwords in a
>>>> database using salted SHA-512 digests
>>> I can't speak to most of this email, but don't do this. SHA-x is a
>>> *fast* hashing algorithm. It's not designed for passwords. The
>>> problem with fast hashing algorithms is that they are *very*
>>> susceptible to rainbow table attacks. Modern password-hacking systems
>>> with 24 GPUs can calculate billions of MD5 and SHA-x hash attacks per
>>> second.
>>>
>>> I strongly recommend you use a *slow* hashing algorithm such as
>>> bcrypt, which is designed specifically for hashing passwords. These
>>> algorithms use more than just CPU/GPU operations (such as memory).
>>> Password hacking systems can only calculate thousands of these per
>>> second instead of millions. It's much better protection in case your
>>> password database is ever stolen.
>> While you are completely correct in your assessment (crypto hashes don't
>> make good password hashes), the fact that Tomcat supports only the
>> former is a somewhat tacit affirmation that simply using crypto hashing
>> for passwords is good security.
>>
>> 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.
>>
>> Since it sounds like there's a bit of appetite for this, I may spend
>> some more time on this (that is, some at all).
>>
>> -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.
Well, out of the box would require two things: salting and iterating.
Password-hashing algorithms are better than just adding salt and
stirring SHD-512 or whatever.
I'd love to be able to directly-support things like bcrypt and scrypt,
but I'm not sure about their licensing and adding an external dependency
isn't a great idea. I think the best we can hope for would be to add
support at the code level for pluggable interfaces, and then put some
samples on the Wiki for how to write a wrapper around something specific
like bcrypt.
-chris
Re: support for salted passwords
Posted by Ognjen Blagojevic <og...@gmail.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: support for salted passwords
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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
Re: support for salted passwords
Posted by Ognjen Blagojevic <og...@gmail.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Re: support for salted passwords
Posted by "Gabriel E. Sánchez Martínez" <ga...@gmail.com>.
On 02/04/2014 12:20 PM, Christopher Schultz wrote:
> Nick,
>
> On 2/2/14, 2:51 AM, Nick Williams wrote:
>> On Feb 2, 2014, at 1:23 AM, Gabriel E. Sánchez Martínez wrote:
>>> I am very new to Tomcat but am already getting my feet wet with a
>>> web application. A requirement for this application is form-based
>>> password authentication, and I would like to store passwords in a
>>> database using salted SHA-512 digests
>> I can't speak to most of this email, but don't do this. SHA-x is a
>> *fast* hashing algorithm. It's not designed for passwords. The
>> problem with fast hashing algorithms is that they are *very*
>> susceptible to rainbow table attacks. Modern password-hacking systems
>> with 24 GPUs can calculate billions of MD5 and SHA-x hash attacks per
>> second.
>>
>> I strongly recommend you use a *slow* hashing algorithm such as
>> bcrypt, which is designed specifically for hashing passwords. These
>> algorithms use more than just CPU/GPU operations (such as memory).
>> Password hacking systems can only calculate thousands of these per
>> second instead of millions. It's much better protection in case your
>> password database is ever stolen.
> While you are completely correct in your assessment (crypto hashes don't
> make good password hashes), the fact that Tomcat supports only the
> former is a somewhat tacit affirmation that simply using crypto hashing
> for passwords is good security.
>
> 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.
>
> Since it sounds like there's a bit of appetite for this, I may spend
> some more time on this (that is, some at all).
>
> -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.
- Gabriel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: support for salted passwords
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Nick,
On 2/2/14, 2:51 AM, Nick Williams wrote:
> On Feb 2, 2014, at 1:23 AM, Gabriel E. Sánchez Martínez wrote:
>> I am very new to Tomcat but am already getting my feet wet with a
>> web application. A requirement for this application is form-based
>> password authentication, and I would like to store passwords in a
>> database using salted SHA-512 digests
>
> I can't speak to most of this email, but don't do this. SHA-x is a
> *fast* hashing algorithm. It's not designed for passwords. The
> problem with fast hashing algorithms is that they are *very*
> susceptible to rainbow table attacks. Modern password-hacking systems
> with 24 GPUs can calculate billions of MD5 and SHA-x hash attacks per
> second.
>
> I strongly recommend you use a *slow* hashing algorithm such as
> bcrypt, which is designed specifically for hashing passwords. These
> algorithms use more than just CPU/GPU operations (such as memory).
> Password hacking systems can only calculate thousands of these per
> second instead of millions. It's much better protection in case your
> password database is ever stolen.
While you are completely correct in your assessment (crypto hashes don't
make good password hashes), the fact that Tomcat supports only the
former is a somewhat tacit affirmation that simply using crypto hashing
for passwords is good security.
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.
Since it sounds like there's a bit of appetite for this, I may spend
some more time on this (that is, some at all).
-chris
Re: support for salted passwords
Posted by Nick Williams <ni...@nicholaswilliams.net>.
On Feb 2, 2014, at 1:23 AM, Gabriel E. Sánchez Martínez wrote:
> Hi developers,
>
> I am very new to Tomcat but am already getting my feet wet with a web application. A requirement for this application is form-based password authentication, and I would like to store passwords in a database using salted SHA-512 digests
I can't speak to most of this email, but don't do this. SHA-x is a *fast* hashing algorithm. It's not designed for passwords. The problem with fast hashing algorithms is that they are *very* susceptible to rainbow table attacks. Modern password-hacking systems with 24 GPUs can calculate billions of MD5 and SHA-x hash attacks per second.
I strongly recommend you use a *slow* hashing algorithm such as bcrypt, which is designed specifically for hashing passwords. These algorithms use more than just CPU/GPU operations (such as memory). Password hacking systems can only calculate thousands of these per second instead of millions. It's much better protection in case your password database is ever stolen.
> , recognizing that this is not state-of-the-art password protection, but it is a more secure method than unsalted digests in the event that the password table is compromised.
>
> <snip />
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org