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