tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Sánchez Martínez <gabrielesanc...@gmail.com>
Subject Re: Re: support for salted passwords
Date Thu, 06 Feb 2014 14:33:04 GMT

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


Mime
View raw message