3 Replies - 789 Views - Last Post: 01 October 2012 - 09:01 AM Rate Topic: -----

#1 valrog   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 1
  • Joined: 28-September 12

Securely connecting to SQL

Posted 28 September 2012 - 02:52 PM

I am wondering how to securely connect to a SQL database. My problem is that within the code is my connection string and C# can be decompiled too easily which would allow someone smart enough to see the connection string, including the username and password.

They would see something like this after decompiling
private string ConnString = Data Source=www.myhostingcompany.com\sql2005;Initial Catalog=uttservicecom;Persist Security Info=True;User ID=username;Password=password;Connection Timeout=45

What is the best practice for securing this information and/or preventing decompilation?

Is This A Good Question/Topic? 0
  • +

Replies To: Securely connecting to SQL

#2 tlhIn`toq   User is offline

  • Xamarin Cert. Dev.
  • member icon

Reputation: 6532
  • View blog
  • Posts: 14,447
  • Joined: 02-June 10

Re: Securely connecting to SQL

Posted 28 September 2012 - 03:14 PM

I'm sure someone else here has an elegant solution. Databases are not my thing. But I want to point out that I see no effort or even 30 seconds of thinking here.

1) You're worried about decompiling. So get Dotfuscator to obfuscate your code

2) You're worried that people we see your connection string. But you named it 'connString'. Might as well just publish it. Is your method also named "ConnectToServer"? That should help them narrow right in on it.

At least put some effort and imagination into this. Hide your variables and methods with names like DoYogiBear(object Booboo)

Hide the username across 20 different variables of 1 letter each, with silly names and assemble it when you need it in a method named "ExitApplication" or a get-only property named "CurrentTime" - do something to cause the hackers to have to work for it.

Hide information in encrypted strings or hashtables that get decrypted at runtime. Or hide them is some obscure registry value that has nothing to do with this application. I mean you weren't going to really leave the application with hard-coded username and password were you? How would you ever make a change? You'd have to recompile your app.

Or hide them in your own proprietary encryption technique. I don't know... generate an array of numbers, add those values to each character of the password - then undo the math at runtime. So your password string is "apple" but stored as "dkgjas" and you have a method that does the decrypt when you need it.

Put half the information in resources instead of the code.
Hide the info using Steganography in a graphic of the company logo.

Hell there must be a hundred ways to hide data if you just put some thought in it.
Was This Post Helpful? 0
  • +
  • -

#3 Viske   User is offline

  • D.I.C Head
  • member icon

Reputation: 24
  • View blog
  • Posts: 70
  • Joined: 07-June 11

Re: Securely connecting to SQL

Posted 01 October 2012 - 08:14 AM

Have you looked in to storing your connection string in the app.config then encrypting using aspnet_regiis? You can see how to do it here.

You'll need ASP.net to use aspnet_regiis.
Was This Post Helpful? 0
  • +
  • -

#4 Curtis Rutland   User is offline

  • (╯□)╯︵ (~ .o.)~
  • member icon

Reputation: 5103
  • View blog
  • Posts: 9,283
  • Joined: 08-June 10

Re: Securely connecting to SQL

Posted 01 October 2012 - 09:01 AM

There are two possible things to do here. If this is a client application, then you shouldn't be directly interacting with a server database anyway. You should have a web service of some kind hosted on the server, and have your application interact with the service. The service can do the database interaction. That way, you completely remove all database code from the client.

Second, if this is Sql Server, use SSPI. Instead of using a SQL account, you use a Windows account that has been set up on the Sql Server. Make sure to use a service account, created specifically for this purpose, with no permissions other than what it needs to do database interaction. Then, you can run your application (for example, the Web Service that will actually interact with your database) under the service account. That way, you need no passwords in configs at all, and you have extremely granular control over the permissions of the account it runs under.

That's your best option. That way, you don't have to try to hide data. The data doesn't exist in the application in any form. It exists above the application, in the hosting environment (IIS). Of course, this doesn't work on a client application, but as we've already discussed, you don't want to directly access a server database from a client application anyway. You always want the web service in between you. That makes it easier to control what goes in and comes out of the database, and it vastly reduces your attack surface.

The trick for encrypting the app.config won't work well for a client application, because it uses machine config values for encryption that will be different on every PC.
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1