You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Sreyan Chakravarty <sr...@gmail.com> on 2015/09/08 12:31:51 UTC
Undefined behaviour with Credential Handler
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 ?
As far as I know it must be same algorithm, salt and iterations for the
hash to be matched perfectly.
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.
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 ?
Regards
Sreyan Chakravarty
Fwd: Undefined behaviour with Credential Handler
Posted by Sreyan Chakravarty <sr...@gmail.com>.
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 ?
As far as I know it must be same algorithm, salt and iterations for the
hash to be matched perfectly.
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.
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 ?
Regards
Sreyan Chakravarty
Re: [somewhat OT] Undefined behaviour with Credential Handler
Posted by "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
Re: Undefined behaviour with Credential Handler
Posted by Sreyan Chakravarty <sr...@gmail.com>.
"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
>
>
Re: Undefined behaviour with Credential Handler
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
Re: Undefined behaviour with Credential Handler
Posted by Sreyan Chakravarty <sr...@gmail.com>.
Yes but that requires implementing your own credential handler. But the
default one will still have the bug. Right now I am thinking of using an
authentication framework like Apache Shiro.
On Thu, Sep 10, 2015 at 1:48 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Sryan,
>
> 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
> >>
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJV8JQpAAoJEBzwKT+lPKRYBlQP/2dedJFcZSsAGF+0uxRGIPfr
> vW26AOOaT/qPS88eQiCucufYOpPx180ifdIdnNVtLRZbIYyeQMBQiFTezMZM1Psx
> 2Ufuw1ZEPV0kZteptnDgGyipZKtDaxl/7hYY76O3yy8ki62Fa6TcRtR8UBPY0pJs
> kVYw9ZWqVVq8smkDomYAA/wwtGUzXORB3RN5yKGtKPx7roV00cLAoKQTv4ZlxfM5
> LMuuorMx9jnWI9JXTlQdxi9ydQ1IlALrv9igbXE1/cYCnLrHtJVrE+bzvL4XPy+1
> C9H8UdWT8Mqdn4qSIi5Zp0JDkRffvjVj4WA7V3Yt2+7HqlcZjEFDdAtN//DJ9T4A
> Zc/NJ73vXyEnFKt1S3mgqTIaGi7tr13VX8mXyFVSXzP/wvoQpCaOr0RYyIVvTdOc
> r42X1j5gq3tKTV1Hxe73SoM9iJivFvq6VFq+zvzv3fdNyHt1TukwM3E7nxnd6cXr
> euWj5IUc1+Z002xQBPKWjxAJFxsmd1cvM9A4zuhr70P2WcTsYSCbTn0ETB7Vtssb
> Rr1ED6jf2MKE/JIU8G6YKU5yuLqAnSaJleHOyWz/N8X5fUN5q4sfeV174UluS1WU
> +J017q60ZBrkEdzPB7bO/Jku1ThPHcFMbg5VfQQ+TTyN6AugQYfvasrvfBhu2wdL
> 3CMQ6Hf+ShnIB8aWI8zj
> =Sxyr
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Undefined behaviour with Credential Handler
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Sryan,
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
>>
>>
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV8JQpAAoJEBzwKT+lPKRYBlQP/2dedJFcZSsAGF+0uxRGIPfr
vW26AOOaT/qPS88eQiCucufYOpPx180ifdIdnNVtLRZbIYyeQMBQiFTezMZM1Psx
2Ufuw1ZEPV0kZteptnDgGyipZKtDaxl/7hYY76O3yy8ki62Fa6TcRtR8UBPY0pJs
kVYw9ZWqVVq8smkDomYAA/wwtGUzXORB3RN5yKGtKPx7roV00cLAoKQTv4ZlxfM5
LMuuorMx9jnWI9JXTlQdxi9ydQ1IlALrv9igbXE1/cYCnLrHtJVrE+bzvL4XPy+1
C9H8UdWT8Mqdn4qSIi5Zp0JDkRffvjVj4WA7V3Yt2+7HqlcZjEFDdAtN//DJ9T4A
Zc/NJ73vXyEnFKt1S3mgqTIaGi7tr13VX8mXyFVSXzP/wvoQpCaOr0RYyIVvTdOc
r42X1j5gq3tKTV1Hxe73SoM9iJivFvq6VFq+zvzv3fdNyHt1TukwM3E7nxnd6cXr
euWj5IUc1+Z002xQBPKWjxAJFxsmd1cvM9A4zuhr70P2WcTsYSCbTn0ETB7Vtssb
Rr1ED6jf2MKE/JIU8G6YKU5yuLqAnSaJleHOyWz/N8X5fUN5q4sfeV174UluS1WU
+J017q60ZBrkEdzPB7bO/Jku1ThPHcFMbg5VfQQ+TTyN6AugQYfvasrvfBhu2wdL
3CMQ6Hf+ShnIB8aWI8zj
=Sxyr
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Undefined behaviour with Credential Handler
Posted by Sreyan Chakravarty <sr...@gmail.com>.
Well I guess now its confirmed that it is a bug. Do you still need the code
?
On Wed, Sep 9, 2015 at 8:55 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJV8E9cAAoJEBzwKT+lPKRYvFUQAJOnonwIc7wdMKSbyn6ldsXT
> +2A1gC16QpAnvWgP8RkqDgDn9zPfYBfdRePpI3voDxNJsiKxSuqPhldlPTtyu+28
> 4KWDifi1qxTbhvMasSv1AgwkzMjOBFWitZ8NLbr4AUK/m878Goc0nSUEDIirpLNq
> THfQAL5fvN0IXl6IqDx5dEyGekBQsSg6Q1NqU5ZL6w2GLvhwYBfTE/eFsHzw/mc2
> Z7IIC/gt7wT4FbkzzMF1Qcp6TKvEA1pdLU0KCcE7BiLCiwJxWfQTCI2WWEJIMV2s
> FwkvLDXidqmNIL6Wg4QoaB093lw5UcQY0r2kUtCL4gkuS7IqCyLeFaaJFXoN2iY9
> +OlLlPF1DrsKAhJejDuge1+ixksWDd3VqL6DoMHqldpG5kh1CIPjO3Cwpnw5ypNX
> /v5u4dq318qrcp2UGsr/1mRXx0t7gNUfgqGqS+4wDw40TekGJbGJqhFaVoq82sjz
> gFPOhjTeSDExb0zTiyhaRus4VtqlGUnMj+CIx+4yMDg1ax/Le19yV7if+p4KRaB+
> Ua+D31QY5sz09CIJIog9WOiQ20PGDsWSgQzKevoqZCDgWfx/NChG5rz0ku0DdHsC
> nednB/m8TGrT6ziT33NIbfDGgp31egkI6TjqVcLaK4IX1L073R83sQ9O6m5pqmJ+
> t5YGoYKn1OMac388Rx7N
> =Ha10
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Undefined behaviour with Credential Handler
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV8E9cAAoJEBzwKT+lPKRYvFUQAJOnonwIc7wdMKSbyn6ldsXT
+2A1gC16QpAnvWgP8RkqDgDn9zPfYBfdRePpI3voDxNJsiKxSuqPhldlPTtyu+28
4KWDifi1qxTbhvMasSv1AgwkzMjOBFWitZ8NLbr4AUK/m878Goc0nSUEDIirpLNq
THfQAL5fvN0IXl6IqDx5dEyGekBQsSg6Q1NqU5ZL6w2GLvhwYBfTE/eFsHzw/mc2
Z7IIC/gt7wT4FbkzzMF1Qcp6TKvEA1pdLU0KCcE7BiLCiwJxWfQTCI2WWEJIMV2s
FwkvLDXidqmNIL6Wg4QoaB093lw5UcQY0r2kUtCL4gkuS7IqCyLeFaaJFXoN2iY9
+OlLlPF1DrsKAhJejDuge1+ixksWDd3VqL6DoMHqldpG5kh1CIPjO3Cwpnw5ypNX
/v5u4dq318qrcp2UGsr/1mRXx0t7gNUfgqGqS+4wDw40TekGJbGJqhFaVoq82sjz
gFPOhjTeSDExb0zTiyhaRus4VtqlGUnMj+CIx+4yMDg1ax/Le19yV7if+p4KRaB+
Ua+D31QY5sz09CIJIog9WOiQ20PGDsWSgQzKevoqZCDgWfx/NChG5rz0ku0DdHsC
nednB/m8TGrT6ziT33NIbfDGgp31egkI6TjqVcLaK4IX1L073R83sQ9O6m5pqmJ+
t5YGoYKn1OMac388Rx7N
=Ha10
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org