Reputation: 12258
If you use SQL Server Authentication (2005), are the login details sent in clear text over the wire?
Upvotes: 8
Views: 7985
Reputation: 5147
Whether or not the login credentials are encrypted depends on the encryption capability/configuration of the client and server.
At the protocol level, completely unencrypted SQL logins are allowed, though my guess is that these are rare because I suspect most modern database drivers do not support them.
Clients communicate with Microsoft SQL Server using the Tabular Data Stream (TDS) protocol.
Shortly after a client opens a TDS connection to the server, it informs the server of its encryption capability. The server compares this announcement with its own configuration/capability to determine the encryption state for the connection.
In a nutshell, the encryption state is determined as follows:
The only way to ensure that login requests are always encrypted is to set the 'require encryption' option on either client or server. There’s no option to disallow completely unencrypted connections without requiring full encryption.
Regardless of whether or not the login or connection is encrypted, the SQL authentication password is always obfuscated but the scrambling is easily reversible.
Upvotes: 4
Reputation: 2263
Reading this thread made me even more confuse then I was! Anyway, I did some tests with Wireshark, with or without encrypted connection I was never able to see my password (and my user name I think). What was very visible without encryption is the actual queries.
Perhaps it is the lack of knowledge with Wireshark to retrieve the login credentials, but since I was able to see everything else I'm pretty sure I was looking at the right spot and the password was ALWAYS hidden.
Upvotes: 1
Reputation: 30873
Apart from the fact that passwords are sent in clear text, it is also possible to replace the hash of the password.
Upvotes: -1
Reputation: 45117
Here's a link to some security best practices for SQL 2005. That doc states in part:
In Windows Authentication mode, specific Windows user and group accounts are trusted to log in to SQL Server. Windows credentials are used in the process; that is, either NTLM or Kerberos credentials. Windows accounts use a series of encrypted messages to authenticate to SQL Server; no passwords are passed across the network during the authentication process. When SQL logins are used, SQL login passwords are passed across the network for authentication. This makes SQL logins less secure than Windows logins.
Upvotes: 2
Reputation: 20175
As secure as you want to make it...
you can configure SSL fairly easily, and if you don't have a trusted cert, if you force encryption, SQL Server can create/issue it's own self signed cert for your use...from this write-up
Credentials (in the login packet) that are transmitted when a client application connects to SQL Server are always encrypted. SQL Server will use a certificate from a trusted certification authority if available. If a trusted certificate is not installed, SQL Server will generate a self-signed certificate when the instance is started, and use the self-signed certificate to encrypt the credentials. This self-signed certificate helps increase security but it does not provide protection against identity spoofing by the server. If the self-signed certificate is used, and the value of the ForceEncryption option is set to Yes, all data transmitted across a network between SQL Server and the client application will be encrypted using the self-signed certificate
Upvotes: 5
Reputation: 32831
The credentials are sent in clear text.
You can probably find a number of sources for this, but here's one:
"Secure the channel between the Web server and database server because credentials are passed in an unencrypted format. For example, use SSL or IPSec."
Upvotes: 2