Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was asked this today and I honestly did not know the answer. If you connect using a connection string without sspi to a server is there any way a 3rd party can intercept on the wire the password used to log in?

"Data Source=MyServer;Initial Catalog=MyDatabase;User Id=sa;Password=CanThisBeSniffed;"

I am not asking about MiTM attacks just someone listing on the same computer or on the same hub on the network with wireshark or something similar running.

I fired up wireshark myself and did not see it in plain text but it could be a simple obfuscation or proper encryption, I just wanted to know which.

share|improve this question
up vote 1 down vote accepted

SQL Server 2000 and up (might be 2005 and up, I forget; it's in my new book somewhere) the authentication process used by a SQL Authentication Login (as opposed to Windows Authentication) is encrypted by a self signed SSL certificate which is generated by the SQL Server instance on install of the database engine.

share|improve this answer

Nick raises a good point, being that blog post wasn't exactly what you were after. Sorry about that.

The MSDN library has specifics about configuring SSL connections

However, the following is slightly ambiguous

Credentials (in the login packet) that are transmitted when a client application 
connects to SQL Server are always encrypted.

It's not entirely clear (to me anyway) if that means they are always encrypted irrespective of the SSL settings, or not.

If you are concerned about it, I would be enabling SSL.

share|improve this answer
that blog post is about how sql server stores passwords, not how a client authenticates with a server across a network – Nick Kavadias Feb 2 '11 at 23:48
Thanks Nick, I've updated my answer. – LukeR Feb 3 '11 at 1:28

I've been doing some digging on this too, and there is a possible MITM attack to force a downgrade - see here

Some older versions of SQL don't support SSL-encrypting the login, and send the password in the clear, so both client and server support fall-back to unencrypted authentication if the encrypted auth fails. But you can't set modern versions of SQL Server to ENCRYPT_NOT_SUP on purpose (note that the attack is to MITM the PRELOGIN session and alter a flag to ENCRYPT_NOT_SUP instead of ENCRYPT_OFF - which is the default mode for SQL).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.