Re: [somewhat OT] Undefined behaviour with Credential Handler

["André Warnier (tomcat)" <aw...@ice-sa.com>]

Hi.

I have been following this thread loosely, and I have nothing about Tomcat authentication 
per se, but maybe now may be the moment to suggest another approach : why not use an 
Apache httpd as a front-end to Apache Tomcat, do the user authentication/authorization at 
the Apache httpd level (in almost whatever flavor known to man, and generally dictated by 
the customer circumstances more than by anything else), and pass to Tomcat requests which 
are already authenticated/authorized ?

Apache httpd having been on the market a bit longer than Tomcat, and having a 
comparatively higher "market share" in terms of number of webserver installations, it has 
already acquired over time a very wide range of user authentication mechanisms, which 
Tomcat doesn't match yet, and will probably never match unless a lot of developer time is 
spent at just that aspect (never mind the developer time that has already been spent at 
it).  Developer time which could probably be fruitfully spent at other more Tomcat- and 
Java-servlet-centric issues, rather than at duplicating what is already solved and heavily 
tested elsewhere.

Installing and configuring Apache httpd as a front-end to Tomcat is fairly easy, fairly 
efficient in operation, and fairly frequent for real-world Tomcat sites, even if not 
always for authentication purposes per se.
Adding user authentication/authorization to such a setup is almost trivial from an httpd 
point of view, and totally trivial from the Tomcat point of view (well, at least with AJP).

And, it would stay in the big Apache free and open-source family.

Re: https://en.wikipedia.org/wiki/Law_of_the_instrument
and https://en.wikipedia.org/wiki/Overengineering

I mean, from a human point of view, I understand the temptation for a Java developer, and 
for a Tomcat Java developer, to do everything in Java and in Tomcat rather than 
somewhere/somehow else.  And I do recognise that in some use cases, one can not do 
otherwise.  But at some point, the more bells and whistles you add to something, the 
heavier it becomes and the more resources are needed to develop, debug, document and 
maintain all that stuff. Isn't it so ?



On 10.09.2015 21:49, Sreyan Chakravarty wrote:
> "Feel free to do that. You'll have to implement a lot of plumbing code
> yourself to use Apache Shiro. (It seems like Tomcat ought to support
> Shiro, eh? Maybe we should get together with them to build an
> out-of-the-box configurable component in Tomcat)."
>
> Well I don't know that but you people could try making Tomcat Container
> managed security easier to use.
>
> On Thu, Sep 10, 2015 at 9:16 PM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Sreyan,
>>
>> On 9/10/15 8:10 AM, Sreyan Chakravarty wrote:
>>> Yes but that requires implementing your own credential handler.
>>
>> Sorry, I thought you had implemented your own credential handler.
>>
>>> But the default one will still have the bug.
>>
>> Oh, I was just suggesting that fix as something temporary until an
>> updated version of Tomcat is released where this bug is fixed. The fix
>> is trivial, so I have no doubt it will be in the next release.
>>
>>> Right now I am thinking of using an authentication framework like
>>> Apache Shiro.
>>
>> Feel free to do that. You'll have to implement a lot of plumbing code
>> yourself to use Apache Shiro. (It seems like Tomcat ought to support
>> Shiro, eh? Maybe we should get together with them to build an
>> out-of-the-box configurable component in Tomcat).
>>
>> - -chris
>>
>>> On 9/9/15 12:50 PM, Sreyan Chakravarty wrote:
>>>>>> Well I guess now its confirmed that it is a bug. Do you still
>>>>>> need the code ?
>>>
>>> No, I don't think I will.
>>>
>>> However, since you wrote your own CredentialHandler, you could
>>> merely patch it to check in the matches() method for null.
>>> Something like this:
>>>
>>> @Override public boolean matches(String inputCredentials, String
>>> storedCredentials) { if(null == storedCredentials) return false;
>>>
>>> return matchesSaltIterationsEncoded(inputCredentials,
>>> storedCredentials); }
>>>
>>> Then you can resume your testing.
>>>
>>> -chris
>>>
>>>>>> On Wed, Sep 9, 2015 at 8:55 PM, Christopher Schultz <
>>>>>> chris@christopherschultz.net> wrote:
>>>>>>
>>>>>> Sreyan,
>>>>>>
>>>>>> On 9/8/15 6:31 AM, Sreyan Chakravarty wrote:
>>>>>>>>> Okay is if I have stored my password in my DB with
>>>>>>>>> SHA256 encryption, can the credential handler declared
>>>>>>>>> in the realm work if the it is declared with SHA512 ?
>>>>>>
>>>>>> No. SHA256 and SHA512 produce hashes of different sizes, so
>>>>>> with the same input, they will always produce different
>>>>>> outputs.
>>>>>>
>>>>>> https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions
>>>>>>
>>>>>>>>>
>>>>>>
>> As far as I know it must be same algorithm, salt and
>>>>>>>>> iterations for the hash to be matched perfectly.
>>>>>>
>>>>>> Correct.
>>>>>>
>>>>>>>>> Now take my case-:
>>>>>>>>>
>>>>>>>>> <CredentialHandler className =
>>>>>>>>> "org.apache.catalina.realm.SecretKeyCredentialHandler"
>>>>>>>>> algorithm = "PBEWITHMD5ANDTRIPLEDES" />
>>>>>>>>>
>>>>>>>>> Okay this my credential handler that I am using. In my
>>>>>>>>> DB the password is stored using
>>>>>>>>> PBEWITHHMACSHA384ANDAES_256. A completely different
>>>>>>>>> algorithm that the one specified before. So how come
>>>>>>>>> when I put in my user-id and password on my form-login
>>>>>>>>> page I am not getting an authentication error instead I
>>>>>>>>> am being forwarded to the protected resource.
>>>>>>
>>>>>> Perhaps PBEWITHMD5ANDTRIPLEDES and
>>>>>> PBEWITHHMACSHA384ANDAES_256 are somehow aliases of each
>>>>>> other? Also, it's possible that your implementation of the
>>>>>> algorithm is flawed.
>>>>>>
>>>>>> Try running the "mutate" method from a command-line driver on
>>>>>> some sample input to see what falls out.
>>>>>>
>>>>>>>>> It should use the algorithm in the CredentialHandler
>>>>>>>>> to mutate the password. Now don't tell me that two
>>>>>>>>> different algorithms offer the same hash.
>>>>>>>>>
>>>>>>>>> What is going on here ?
>>>>>>
>>>>>> My guess is a bug in the CredentialHandler itself. Can you
>>>>>> post some cod e?
>>>>>>
>>>>>> -chris
>>>>>>>
>>>>>>> ------------------------------------------------------------------
>> - ---
>>>>>>>
>>>>>>>
>>>
>>>>>>>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail:
>>>>>>> users-help@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>> -----BEGIN PGP SIGNATURE-----
>> Comment: GPGTools - http://gpgtools.org
>>
>> iQIcBAEBCAAGBQJV8aXyAAoJEBzwKT+lPKRYav4P/jogPWNaIJLqlX8tFLMvE4th
>> 78dDP553/snHIZ+/g27ZyD2P3yIAcD1MURgO1B8k0GDJrbxQdLrtvW8jNt1J8UN8
>> M0Wa68PrWxyy8uFecOhvHDwBd749teNl5Z/EimlzooC4FY5cFWCUgsY4qRAfd3/r
>> aApCpSkNKOGGcJJ1RQuUYRski72H6OezzhSZthbgr+9YYtDtpxpkeJ2UikWfzeFc
>> 1sl5B1wbjAl/Da8YU1tM5SNgCHLR5MAA2WDJlTyHHQrG42lhp8aE5FHVs62xT/VD
>> 1v4tJP1mFNc709tKpd+hnvCczjMd4BaPP2rKmaEozhuGPyfNpPcGP1xQAmBIvWR9
>> 0RaEk1UhpwQdaS1kxOqBHLYLmplhmt9BS4AFy7WUcWZfiEGqi9IvG3Oblt2OinRb
>> 68b4fQbgiW4NBBccw1yFYQ8XAQCxtB340b8j7y8OiMWihgWtxtmpNrazW0AoHgV/
>> QcYlhQ8fldwa5ysbefvZC82eQJ0s0ivvsX7iclNCJHOUW48oud9nscHu9r+3pBm3
>> s3bbpnXGrFFNwZpSGmvlQ7im0Ozv+huuqe7vg3pGryWxte5+I54m8y7xkQs0mTZF
>> tGjYDk20qn30j/Oke5AO99fVzpgJl9jlBVY+CrPTKKm3GzEj8cBl92jnN8flzjZP
>> fwwURalFrQjt3tbqNUvW
>> =JROa
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org