https://issues.apache.org/bugzilla/show_bug.cgi?id=51966
--- Comment #17 from S <bl...@gmx.net> --- (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). > 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
