-----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