Does the password get sent in the clear when connecting to Sql-Server?

Question

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.

Answer 1

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.

Answer 2

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 http://msdn.microsoft.com/en-us/library/ms189067.aspx

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.

Answer 3

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