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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
