Re: [somewhat OT] Undefined behaviour with Credential Handler

[tomcat]

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





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