> -----Original Message----- > From: peter.crowth...@googlemail.com > [mailto:peter.crowth...@googlemail.com] On Behalf Of Peter Crowther > Sent: Thursday, February 24, 2011 3:57 AM > To: Tomcat Users List > Subject: Re: [OT] Memory Leak in Tomcat > > On 24 February 2011 09:42, André Warnier <a...@ice-sa.com> wrote: > > > 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. > > > > André, I'd be interested in how you arrived at these assertions. In > particular, I don't believe your first sentence. I can start a service > that > logs on as a domain account when my domain member (a laptop) is not > connected to the domain. Therefore the domain member is storing > something > somewhere, not just the DC. And any time "something" is stored > "somewhere" > it is subject to attack, as the Linux-based tools for changing Windows > administrator passwords demonstrate rather well - Windows may not allow > direct SAM hive access, but a foreign OS has no such compunctions. >
The local Windows OS caches logon credentials and does a local authentication iff the domain controller is not available -- specifically for the purpose of allowing logins in that case. Those credentials are stored somewhere on disk (probably somewhere under C:\Windows\security, or perhaps in the registry), and potentially usable by an attacker. However, if the credentials cannot be verified by other networked machines, those systems are supposed to reject them. My original point was that I don't know the mechanism for storing credentials in the Services. It appears that they are store in the registry, but I cannot tell if they are encryptions of the credentials themselves or the token returned from authentication. In either case, if you change the password on the domain, you have to change it on the service or it won't start. > This is all a long way from the original subject, of course. I > routinely > use SSPI authentication to SQL Server when I can do, as it does reduce > the > attack surface somewhat. SSPI generally makes it harder for an > attacker to > retrieve the credentials used to authenticate a database client to SQL > Server. It makes no difference to any attack that subverts the client > directly in order to attack through an existing or client-created new > connection, of course. > > - Peter p.s. before the spell-check nazi's comment on it, the "iff" above was intentional. __________________________________________________________________________ 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. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
