tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 51966] Tomcat does not support ssha hashed passwords in all contexts
Date Thu, 06 Feb 2014 02:55:19 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=51966

--- Comment #19 from Gabriel <gabrielesanchez@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message