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
signature.asc
Description: OpenPGP digital signature
