On 23/09/2014 00:56, "Gabriel E. Sánchez Martínez" wrote: > > On 09/17/2014 04:36 AM, Mark Thomas wrote: >> On 16/09/2014 22:14, Christopher Schultz wrote: >>> Mark, >>> >>> On 9/16/14 3:39 PM, Mark Thomas wrote: >>>> Updated patch: >>>> http://people.apache.org/~markt/patches/2014-09-16-bug56403-tc8-v2.patch >>>> > It's looking good!
I have an updated version I need to upload that addresses the remaining issues. <snip/> > This would be good. One could have an array of CredentialHandler to > check in order. Is the idea that a password stored in an old format > would be matched using the old CredentialHandler and (upon first match) > stored in the upgraded format (the first CredentialHandler)? I assume > the same idea goes for when the same CredentialHandler is used but the > number of iterations has changed. The Realm API has no mechanism up writing to storage. That doesn't stop a custom realm doing this but it isn't (currently) part of Tomcat's API. <snip/> > I saw that String.equals(String s) is being used. I'm not familiar with > the implementation but I imagine that if the string lengths differ or if > the first characters don't match, for example, the method returns false > without checking the rest of the characters. Perhaps that could lead to > a small vulnerability in which through many attempts and timing an an > attacker can infer whether the password length, etc. is right. I've > seen some implementations use a SecureEquals that tries to take > approximately the same time by comparing all characters of the strings > even if the lengths or first characters don't match. Is this a real > concern, or only theory? It is a real concern in that such an attack is possible. However the number of requests necessary for such an attack to be successful are far higher than the limits imposed by the LockOutRealm so Tomcat should be protected against this attack. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
