-----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 <
>>>> [email protected]> 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: [email protected]
>>>>> For additional commands, e-mail:
>>>>> [email protected]
>>>>>
>>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
-----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: [email protected]
For additional commands, e-mail: [email protected]
