13

Quick intro: Small company, VERY limited resources. I pretty much do everything including coffee. I am a programmer, not a security guy. That's why I ask you...

We have an MS-SQL 2008 Database running on our server and several C# Applications that connect to the Database directly using a connection string like this

"Server=example.org; Database=SomeDatabase; User Id=dbUser; password=**secret**; Encrypt=YES"

The applications do not run on the server, so the Database instance is facing to the outer world. This setup is running great, but I have some concerns.

1) What does the Encrypt=YES exactly mean? Is the whole connection (including logon etc.) safe (assuming nobody gets hands on the connection string)? Or should I have serious concerns? What are these concerns (keywords appreciated)?

2) What is a good strategy to distribute the connection string?

To explain the second question: It is very comfortable to connect just directly. The distribution of the connection string could be replaced more easily than wrapping all calls to the database into another more secure channel...

| improve this question | |
  • I am pretty sure this is your ouch part: "so the Database instance is facing to the outer world" – BozoJoe Mar 8 '14 at 7:12
  • Note that up to at least SQL 2014 RTM, TLS 1.0 is the best protocol available to SQL Server, and you'd need to use something like Microsoft Message Analyzer to see which particular cipher suite is being negotiated between a particular client and SQL Server instance - on most systems, RC4 is still available on the default list along with stronger cipher suites. At minimum, use SELECT * FROM sys.dm_exec_connections and verify that ENCYRPT = TRUE for your session ID! – Anti-weakpasswords Jun 21 '15 at 0:27
  • An additional security measure could be to block anything except the specific IP your webapps run on, or better, set a VPN between the two servers and tunnel every connection to the database through it – BgrWorker Jan 26 '17 at 16:15
10

"Encrypted connections" to SQL Server use SSL. That's about as good as you can get. Remember, though, that SSL protects only the connection, i.e. the data as it transits between the client and the SQL Server. It does nothing about how the data is stored on the server. It also does nothing about isolating connected clients from each other; that part is entirely up to SQL Server.

In the "connection string", the password is of course the sensitive part. Each client should have its own user account and password, so that in the event that one password is compromised (a likely event in the long run, unfortunately), you can reset that specific password, without impacting the other users. For password distribution, don't send it as cleartext over the Internet ! Which means: no email; if done Web-like, use HTTPS, not HTTP. In some contexts, it could be reasonable to exchange the password over a phone call.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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