https://issues.apache.org/bugzilla/show_bug.cgi?id=51966
--- Comment #19 from Gabriel <gabrielesanc...@gmail.com> --- (In reply to S from comment #17) > (In reply to Christopher Schultz from comment #16) > > This is awful security. When the client is involved in authentication, > > that's called not being authenticated. > I don't understand. It's the same Tomcat does out-of-the-box (send data to > j_security_check and wait for the result), but with more hashing. > > > In production, we salt-hash 75000 times by default, and should probably do > > more. 10k times isn't nearly enough. > I'll test how long a client takes for 100K and if its acceptable (which I > assume) I'll change. > > > > This way there is never send a unhashed password (even not when you are > > > not > > > using https, which you shouldn't) > > Shouldn't use HTTPS, or shouldn't send otherwise-unencrypted passwords over > > HTTPS? Both of those sound like bad advice. > I meant: You should use https. I can't see the problem generated by sending > a (salted, many-round) hash (with the exception of rainbow table attacks). Hashing on the client side has its merits as long as you also hash on the server side and you don't use the same salt on the client as you do on the server. In particular, if your client code fetches the salt corresponding to a username, that lets an attacker know if they have a valid username (if they receive a salt from the server to do hashing on the client side). If you use a random salt generated for a client session or even a constant client-side salt, it is best to also hash on the server side with an independent user-specific hash. If you hash on the client side but not the server side, and an attacker steals the password table, they essentially have all the passwords they need to get into your site. They don't need to know the cleartext passwords... they can modify the javascript on the client side to send the stolen hash (and not hash again) and the server will let them in. This is why strong hashing on the server side is necessary. > > > Nobody should be using SHA-1 anymore for authentication. > > Realistically, nobody should be using crypto hashing for password hashing, > > anyway. > The second Tomcat supports SCrypt or BCrypt I'll change. What's your > suggestion for the time being? > Besides changing Tomcat yourself like in > http://stackoverflow.com/questions/12285604/writing-a-custom-tomcat-realm- > using-bcrypt, which I really don't want to do. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
