> -----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. __________________________________________________________________________ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
