Jeffrey Janner wrote:
-----Original Message-----
From: André Warnier [mailto:a...@ice-sa.com]
Sent: Thursday, February 24, 2011 3:43 AM
To: Tomcat Users List
Subject: Re: [OT] Memory Leak in Tomcat
Jeffrey Janner wrote:
..
Not sure exactly what Windows does once you've entered a verified
user/pw combination for a service. I'm guessing that it stores the
password somehow, because if you change the password, the service won't
start next time.
It is stored in whatever format, encrypted or not or hashed or not, in
whatever store the
Domain Controller uses to store user credentials.
It doesn't matter.
NTLM authentication afterward works using "tokens" which somehow encode
the information
needed by a server to verify that the client is who it says it is, and
the server is who
it says it is.
The point is that the password is not stored in clear on the client,
when "client" means
whatever host is trying to authenticate itself. It is of coursee
fleetingly in memory at
some point, to construct the authentication tokens, but is not kept.
Only the token is kept.
However, this is a "nice" (?) feature of using SQL Server. Already
validated user credentials can be passed by the OS to SQL Server to be
validated for database logon. It's their version of SSO for the
database. (Note: I don't find it an overwhelming advantage for
determining to use that specific database software.)
No it isn't, not in this case.
in the current scenario, the "user" for which there is SSO is the user-
id under which the
Tomcat process itself is running. It is /not/ the users which connect
to Tomcat and run
the applications.
All these users connect to Tomcat, and are or not authenticated using
whatever method
Tomcat implements.
But then, the credentials used to connect to the database are the
credentials of the
Tomcat process, not the ones of the users.
That is why is was questioning how much in fact of a security this
brings.
The problem is merely moved, to the level of how users authenticate
with the Tomcat
application. Once they have done that, they can access any information
which is accessible
by this Tomcat user.
Isn't that the point of authentication in the application/Tomcat? (Note, I'm
intentionally misinterpreting your use of the term "Tomcat user" here, as you
seem to be mixing the different authentication levels in your argument.)
Here's the proper setup the OP is attempting to implement:
1: End user's authenticate the application using whatever method they deem
necessary.
2: Tomcat/application authenticates to SQL Server either via plaintext uid & pw
stored in XML file, or via SSO token derived from Tomcat process login.
The differences:
a) The plaintext is available rather easily to anyone who can access said XML file, either via Tomcat or some other means. Those credentials can be used to launch an attack on the DB from the Tomcat server, or any other server.
b) The SSO is available directly iff the attacker manages to crash Tomcat or infect it and the attack must take place via the Tomcat process.
c) It is probably possible to grab the Windows SSO token used by the Tomcat
process by locating it on disk and somehow making it useable for attacking the
SQL Db. I don't tread too deeply in the security waters, but I think that
would have made big news if it was easy.
Note: I'm not particularly trying to argue that this is an "ultimately secure" mechanism
for authenticating Tomcat to the SQL Server database. But it does allow the checking of the box
next to "No passwords stored in cleartext" line on the security gestapo's checklist.
Hi.
I agree with all of the above, and maybe I did not say it clearly, but that is also what I
meant.
1) authenticating the Tomcat process to the DB system by means of an NTLM-based
authentication, is a degree more secure than via a clear-text userid/password combination,
because it this last case, the userid/password combination have to be stored somewhere on
the Tomcat server in clear.
2) this however, by itself, does /not/ provide a Single-Sign-On capability for the users,
at least not vis-a-vis the DB system. A true user-level SSO would have the *user*
credentials being used to authenticate to the DB system, which is not the case here.
The only user authenticatiing to the DB system, is whatever user-id Tomcat runs
under.
3) This is what I meant by "merely displacing the issue" : whichever user is "accepted" by
Tomcat can now use the Tomcat applications to access the contents of the database. That
is because Tomcat is authenticated to the DB system, and all accesses to the DB are made
by Tomcat under its own user-id.
So now the issue is : how (and even if) the users authenticate to Tomcat.
(The OP did not mention that part).
Let me give a stupid example : imagine that Tomcat authenticates users by means of the
conf/tomcat-users.xml file.
Then getting hold of /that/ file would allow anyone to login to Tomcat, and automatically
gain access to the database (through the Tomcat applications) without any further check.
Also, because there in fact a single user (Tomcat) accessing the DB system, on behalf of
multiple real users, the type of access granted in the DB system to this "Tomcat user"
must by force be very broad. In other words, if 99% of the users of the Tomcat
applications need only read access to some information, but 1% of these users need also
write access to it, you will have to give the "Tomcat user" r/w access.
Which means that now the only way of preventing the other 99% to write there, is to do it
at the application level.
4) a real secure system (and SSO mechanism) would have the users authenticating to Tomcat
via a secure method, and the Tomcat application using those same user credentials to
authenticate to the DB system on behalf of the user.
This way, the DB system would know who is accessing it, and be able to grant access or not
to selective information, based on who the user is.
But from what I understand, that is not what the OP's jDTS/ntlmauth.dll
combination does.
It does obtain the "Tomcat user" credentials, and logs in to the DB system
using those.
On the other hand, a servlet filter like Jespa authenticates the real user accessing the
Tomcat application, and allows the Tomcat application to use these credentials to
authenticate to a further service.
It is another philosophy and another kind of setup, and I am sure that there is room in
this world for both of them.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
