"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 <
ch...@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 <
> >>>> ch...@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-unsubscr...@tomcat.apache.org
> >>>>> For additional commands, e-mail:
> >>>>> users-h...@tomcat.apache.org
> >>>>>
> >>>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
