I have a web app developed with CSLA 3.6. Now I need to develop a local module wich will work with the same BO and database.
The subject is my question. You know the connection string is readable in the app.config file of WPF application, just open it in the notepad anda then you'll have all you need to access the database, even with Excel. That's not what I want neither my client.
How can I hide the connection string in the app.config file or what I must do to avoid that security leak?
Thanks in advance for your time reading my post.
Definitely this isn't a Csla question. Have a look at How to: Secure Connection Strings When Using Data Source Controls or ask google
encrypting the connection string in web.config
encrypting the connection string in app.config
This can also be an architectural question.
Ultimately even "encrypting" the connection string on a client workstation is really just fancy encoding. This is because the key to decrypt the data must also be on the client workstation. So any half-decent hacker or good developer would be able to get the key and decrypt the data.
Like any security question you must do THREAT analysis. What is the scenario you are trying to prevent? Who is the attacker? What is the cost of a breach? What is the cost of mitigation? Is it worth addressing?
If your "attacker" is end users or even typical IT admin types, then encryption is probably quite sufficient. And you don't need to get fancy either - simple encryption is sufficient because you are relying on their ignorance of getting the key and writing a few lines of code as your barrier.
If your attacker is a developer and/or hacker that can gain access to the client workstation, then encryption is basically useless.
That brings us back to architecture. These days the primary reason for using 3-tier deployments with an app server isn't scalability, it is security. By using an app server, the connection string is moved off the client workstation to the app server. Usually that server is physically more secure, making it much harder for a developer or hacker to gain access to anything in the config file - with or without encryption.
...That brings us back to architecture. These days the primary reason for using 3-tier deployments with an app server isn't scalability, it is security. By using an app server, the connection string is moved off the client workstation to the app server. Usually that server is physically more secure, making it much harder for a developer or hacker to gain access to anything in the config file - with or without encryption.
Thank you Rocky for your response, it was a very good explanation and I still need your help.
I wrote this post because I thought it could be an architectural matter, not a simply connection strings encrypting.
I decided to get in the architecture because hackers does not have hacker badge :-), so any employee could be one. Also, this system manages some critical information and it could be an operational disaster if an intruder gains unauthorized access to the database.
At this point, I have some new questions.
The web app is based in the Optimal Performance Web Client architecture, now I need a local app to interact with the same database using the same bussiness objects.
The scenario is as follow:
MyApp (connection string in web.config file)
And now I also have
same database (in hosting)
MyAppLibrary (local delivered in end user machine I think)
MyWPFApp (connection string in app.config file)
Is possible to set a constant inside the BO MyAppLibrary with the connection string? Maybe overriding some method from CSLA (I apologize if it sounds crazy) I know if I change the database server I will have to deliver again the WPFapp but does not a problem to me.
If the preceding solution is not possible then I must implement the application server solution. My web app is running now and it won't be good to stop for few days and re-design the system. Will the application server implementation bring any changes to the web app?
Thank a lot Rocky
If your threat is from a hacker, then putting the connection string as a constant in code won't help. Ildasm will reveal it with almost no effort...
Thanks Rocky. I hope not bother you so much.
And this question Will the application server implementation bring any changes to the web app?
Please do you have in your site information with more details about "Configuring the Data Portal Server" than in "Expert VB 2008
Business Objects" book?
I've been looking at WcfHost website in the ProjectTracker and the WcfPortal.svc has just one line: <% @ServiceHost Service="Csla.Server.Hosts.WcfPortal" %>
and in the WcfHost references there are two wich get me a little confused: PTWfActivities and PTWorkflow.
Thanks a lot.
You don't need to change your web app at all if you don't want to.
Just set up an app server to support the smart client workstations.
There's a lot more information in the 'Using CSLA 4' ebooks on http://store.lhotka.net - one of the books is entirely focused on data portal configuration options.
Thanks a lot Rocky.
I've read all concerning in "Expert VB 2008 Business Objects" book and I think I understood this matter.
I'm going to try hoping I've got the main point.
You explained very well in that book and I'm begging it'll as simple as it looks.
I bought CSLA 4 books but I'm still working in CSLA 3.6, because for moving into CSLA 4 I need to learn C# first.
I'm VB developer and my job can wait for me learning both things at the same time, at least not now.
Thank very much for your help, your time and your patience.
Unless moving to C# is a personal goal, there's no reason you can't continue to use VB with CSLA 4.
Copyright (c) Marimer LLC