.net protecting application secrets
Hi Experts,
I have a maybe simple or maybe strange question.
I'm just looking for how is this normally dealt with, what is the practice?
For a Windows form application to access a SQL server, (or other things) it will need that login information available somewhere, somewhere also the user will have access to. At the same time you might not want everyone in your organization to have direct SQL access to your database. So you'll need to protect this type of information, even from the users.
At the same time I understand it's relatively easy to de-compile any .net program and get back to something very close to the source code. So even things written in your code is not really "safe".
Connection strings I assume you would often want to put into a separate file so it's easy to change, without having to re-compile and distribute your program. You can encrypt that in the file so it can't easily be read by anyone. But you need to keep the key to de-crypt it again somewhere. I'm guessing this would normally be kept in the code itself and not saved externally in plain text. (You can't encrypt the key used to de-crypt the same key.)
So if anyone can de-compile your .net code, read through the code and find the key (and salt value etc) they also know how to de-crypt the connection string.
Then how do you protect that "application secret"?
I can think of a few ways to try to deal with it.
-Tools to obscure your code (code obfuscation, I guess is the correct term) would make it more difficult to find the key, I guess?
-In terms of SQL login you move the security to the SQL server and limit the application user - can't login with Management Studio, can only run stored procedures etc.
-If other languages is harder to de-compile or disassemble, maybe create a .dll in for example C that handles the de-cryption?
So how do you normally protect information like encryption key etc?
Ronny
I have a maybe simple or maybe strange question.
I'm just looking for how is this normally dealt with, what is the practice?
For a Windows form application to access a SQL server, (or other things) it will need that login information available somewhere, somewhere also the user will have access to. At the same time you might not want everyone in your organization to have direct SQL access to your database. So you'll need to protect this type of information, even from the users.
At the same time I understand it's relatively easy to de-compile any .net program and get back to something very close to the source code. So even things written in your code is not really "safe".
Connection strings I assume you would often want to put into a separate file so it's easy to change, without having to re-compile and distribute your program. You can encrypt that in the file so it can't easily be read by anyone. But you need to keep the key to de-crypt it again somewhere. I'm guessing this would normally be kept in the code itself and not saved externally in plain text. (You can't encrypt the key used to de-crypt the same key.)
So if anyone can de-compile your .net code, read through the code and find the key (and salt value etc) they also know how to de-crypt the connection string.
Then how do you protect that "application secret"?
I can think of a few ways to try to deal with it.
-Tools to obscure your code (code obfuscation, I guess is the correct term) would make it more difficult to find the key, I guess?
-In terms of SQL login you move the security to the SQL server and limit the application user - can't login with Management Studio, can only run stored procedures etc.
-If other languages is harder to de-compile or disassemble, maybe create a .dll in for example C that handles the de-cryption?
So how do you normally protect information like encryption key etc?
Ronny
Dennis Aries
A system we use is to hand out a random key on each initial contact that will be used for further data exchange. Therefor the first contact is virtually unencrypted but in result, no key is stored in either code or on the client side.
Your question is neither simple nor strange.
Almost every developer want's their application hacker safe, the sad part is, it's no more than wishful thinking, especially for a .net application.
This may further enlighten you. http://stackoverflow.com/a/651375
Almost every developer want's their application hacker safe, the sad part is, it's no more than wishful thinking, especially for a .net application.
This may further enlighten you. http://stackoverflow.com/a/651375
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi VikingOnline,
Re:
Alan ";0)
Re:
At the same time I understand it's relatively easy to de-compile any .net program and get back to something very close to the source code. So even things written in your code is not really "safe".I didn't know that, I always assumed that if you define a named connection string in the site web.config that would be secure.
<connectionStrings>
<remove name="cnAspNet" />
<add name="cnAspNet" connectionString="Data Source=tcp:sql2k805.somereputablehost.net;Initial Catalog=SQL2008R2_aspnet;Connect Timeout=15; pooling='true'; Max Pool Size=200;Persist Security Info=True;User ID=aspnet_user;Password=secret" providerName="System.Data.SqlClient" />
</connectionStrings> ' Create Instance of Connection and Command Object
Using myConnection As New System.Data.SqlClient.SqlConnection(ConfigurationManager.ConnectionStrings("cnAspNet").ConnectionString)
Using myCommand As New System.Data.SqlClient.SqlCommand("Rica_BookUpload_Ins", myConnection)
' Mark the Command as a SPROC
myCommand.CommandType = System.Data.CommandType.StoredProcedure
' Add Parameters to SPROC
...
' Populate parameter, @ID int = null output
Dim prmID As New System.Data.SqlClient.SqlParameter("@ID", System.Data.SqlDbType.Int)
prmID.Direction = Data.ParameterDirection.InputOutput
prmID.Value = intID
myCommand.Parameters.Add(prmID)
Try
' Open the connection
myConnection.Open()
' Execute the stored procedure
myCommand.ExecuteNonQuery()
End If
Catch SQLexc As System.Data.SqlClient.SqlException
Me.lblErrorMessage.Text = SQLexc.Message
Me.lblErrorMessage.Visible = True
End Try
End Using
End UsingAlan ";0)
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Server access is done at the web root level. simple put the connection string above the root. Then only a privileged processed on the server can access the connection string and passes the handle to the app. That allows full authentication to be on the server using sessions.
Cd&
Cd&
ASKER
Hey guys,
Thank you for all your answers.
I'm glad it was not as strange question as I was afraid it would be. I guess it's a concern for many, both from security and from protecting your code. Luckily I'm sure nobody wants to steal my simple code.
Some of the answers are asp.net and folders on web.config and make sure that file is outside reach. This is for a web form and not asp.net.
Thank you for all your answers.
I'm glad it was not as strange question as I was afraid it would be. I guess it's a concern for many, both from security and from protecting your code. Luckily I'm sure nobody wants to steal my simple code.
Some of the answers are asp.net and folders on web.config and make sure that file is outside reach. This is for a web form and not asp.net.
ASKER
Tedbilly, yes, if you are in a domain environment then I can see Windows authentication working for protecting SQL. Although it would only be for SQL and still leave encryption keys for example. I guess you could put it into the SQL server and request them from there. But then I guess you could always "listen" on the network communication from the program etc.
But I guess you are at least making it a little more difficult to and the level of technical knowledge to decompile, read code, listen to network traffic is starting to be a lot. It's beyond a "normal user" so someone in the organization would need help from someone outside etc.
But I guess you are at least making it a little more difficult to and the level of technical knowledge to decompile, read code, listen to network traffic is starting to be a lot. It's beyond a "normal user" so someone in the organization would need help from someone outside etc.
ASKER
Dennis Aries, I'm not sure if I follow. Somehow the first contact has to be made. That has to somehow identify you as someone to give a key to. If you know how to request for a key, you can just write your own program or something to send a request for the key. Or something I'm missing?
ASKER
ElrondCT, yeah I can see this being one solution. Obfuscation and if that also encrypt strings, that would make it a lot harder.
And I guess like Tedbilly says, unmanaged code makes it even harder. And at that stage you should be talking professional hackers and not just a hobby computer guy.
And I guess like Tedbilly says, unmanaged code makes it even harder. And at that stage you should be talking professional hackers and not just a hobby computer guy.
ASKER
Satsumo, OK, I see where you are going. That solves the SQL login as you just send information to a server service that can have all sort of validation before passing it on to SQL.
I guess it's a solution similar to the Windows authentication when it's outside a domain structure and outside a way to use Windows authentication.
I think writing a server service like that is a little outside my knowledge level, but at least I see where you are going with it.
I guess it's a solution similar to the Windows authentication when it's outside a domain structure and outside a way to use Windows authentication.
I think writing a server service like that is a little outside my knowledge level, but at least I see where you are going with it.
You might consider using something like Node.js to simply the process of writing the server. This really isn't my area of expertise but its something I've thought about too.
ASKER
Again, thank you for all your replies. I shared out the points to some of the suggestions.
In the end I guess it comes down to how big the need for protection is. For example a trading company that needs to comply with SSC regulations on information, or banks etc. etc. is in one far side of the scale, whilst on the other side of the scale could be some simple tools for the local sports team can be annoying if someone erases your data or mess up your systems but you'll get over it.
Professionally, domains and Windows based access can help a lot.
On smaller scale obfuscation and unmanaged code are your friends.
And depending on the situation, pushing something back to a central server could help keep something further away from end users.
In the end I guess it comes down to how big the need for protection is. For example a trading company that needs to comply with SSC regulations on information, or banks etc. etc. is in one far side of the scale, whilst on the other side of the scale could be some simple tools for the local sports team can be annoying if someone erases your data or mess up your systems but you'll get over it.
Professionally, domains and Windows based access can help a lot.
On smaller scale obfuscation and unmanaged code are your friends.
And depending on the situation, pushing something back to a central server could help keep something further away from end users.