I have an encrypted password in a connection string, contained in a web.config file. I do not know what the password is, and thus cannot connect to my database.
I ran aspnet_regiis.exe -pdf against the web.config and received the following:
Decrypting configuration section...
Succeeded!
I guess I had assumed that the password would be displayed on the screen, or something close to that? Then I thought the program might create a log file with the information in it? Couldn't find one.
I know I am missing something fundamental, I just don't know what it is.
You cannot decrpty the encrypted password.
The whole point of encrypting the password is so that no one is able to decrpty and find what the password is unless you know the key.
When you encrypt the connection string, the key is automatically created and stored in the machine where the encryption was done.
So, if you copy the web.config file to some other machine and do the decryption using:
aspnet_regiis.exe –pdf “connectionStrings” YourPathToWebConfigFile
This won't work.
And to answer your question, if the encryption and decryption was done on the same machine, then your web config file will change automatically with the plain text (decrypted data) for connection string , not that the password would be displayed on the screen.
Run below command
aspnet_regiis.exe –pdf “connectionStrings” C:\inetpub\wwwroot\MyApplication
C:\inetpub\wwwroot\MyApplication needs to be the path where your web.config file is. Once you finish executing above command check your web.config file. If it worked OK you will have decrepted connection string section.
Related
I have a scenario where I am trying to develop a small program where user can set a password and than give these same exe file to multiple user to set this password on some others computers.
My problem is: how can I store this encrypted key in hidden text where no other user can get this value? I have tried setting.settings file; it works until I copy the exe file and use it on other computer - it lost the data.
I hope I have explained well.
I am very new on c#/Visual Studio and I'm having difficulty on running my test methods. It requires us to connect to a database server resulting of getting always a failed result since we can't connect to the database.
We tried to modify the connection string to include our working credentials so that we can connect to the database server but the app.config file was encrypted.
Please see below screenshot of example encrypted line. How can we modify that?
As I see it I think the connectionstring is encrypted outside the project and pasted here. I am saying this because IMO encrypting just the connection string value and keeping the key in plain text is not possible from within the project. It is possible to encrypt the entire section within a config file.
Check the method which is using this connectionstring. I believe The method might be using some form of decryption. Use that to decrypt the string, change the values as required, encrypt it again and paste it in the above location.
You can also edit your question to include the method which is using the connectionstring so that I can analyse it and give you a better solution.
Hope this helps.
How do I get the ConnectionString from the app.exe.config at runtime when the app.exe.config has been encrypted?
When you are on the SAME machine and used the standard encryption methods you can access the connection string just like it has never been encrypted.
ConfigurationManager.ConnectionStrings[]...
You just can't move the config to another machine. Always encrypt on the machine where you want to decrypt it.
Consider the following Link with Code Sample...
http://www.codeproject.com/Articles/186234/Encrypt-Net-Configuration-file
Good Luck!
I have an application, where I should connect to a SQL Server. It is protected by password. So when I'm starting program for the first time, I'm creating dynamically connectionString and save it in app.config. For the next times I can use created connectionString. I've googled and decided to do following: encrypt connectionString in app.config and save password in my code. When I would like to connect to database next time, I will decrypt connectionString, add userId and password and connect with new connectionString to server. Before closing program, I will delete userId and password from connectionString and encrypt it again. But I have some questions:
1) Is it a good solution?
2) When I am starting program for the first time, I need to create connection string, so somewhere in code should be userId and password. How to deal with this problem?
As I understand you create connection string dynamically. So you can encrypt this section from code as well. The encryption algorithm by default will use your machine key to encrypt the section, here is the link how to do it http://www.dotnetcurry.com/ShowArticle.aspx?ID=185
Before closing program, I will delete userId and password from connectionString and encrypt it again
That's not a good solution. Your data should always be encrypted or at least be lost on program termination. If your user kills your program using the task manager (or it simply crashes), and you rely on the fact that your program will encrypt data on exit, your data is left unencrypted.
You could encrypt the whole connection string at the point you get the username and password. Then, any time you want to connect, decrypt it, pass it to the required functions and get rid of it. Never persist it in an unencrypted way.
Create DBUsername, DBPassword and other DB entries as keys in the app.config. For the DBPassword, encrypt it (symmetric probably) using a master key that is hard coded in code. This is generally enough. There are other ways such as the use of a key store to store the key.
If you don't want to construct the conn string each time, create the app config entry holding the entire connection string and encrypt the whole thing with the master key (I see no value here).
If you're using windows and the credentials are the same as your windows authentication, you can omit the username and password from the connection string and replace it with Trusted_Connection=true
I want to encrypt my "ConnectionString" settings which is located in app.config.
But at the Runtime, I want to use( read ConnectionString ) it directly, without decrypt it.
I mean, I don't want to anyone to decrypt the string. There should be NO decryption method.
I'm thinking; it should be like embed .net/asp.net/iis feature to use.
Like "Windows Login" ( you can enter it, use it, but you can't decrypt )
===
An Example Usage; You have small website with some critical data.
You have no money to buy private server,
so you are working on shared server, if the server hacked somehow,
you application and database will be stolen.
But if you put encrypted connectionstring in app.config,
This will be hard to decrpt it and see what is inside in Database.
Encrypting and decrypting configuration settings in a config file can be done from the command line using the aspnet_regiis.exe tool.
The details are described in the following MSDN article:
Encrypting and Decrypting Configuration Sections
As the tool is mainly intended to be used with Web applications, it expects the config file to be named 'web.config'. This means that you temporarily will have to rename your app.config file to web.config:
rename App.config web.config
aspnet_regiis -pef connectionStrings . -prov DataProtectionConfigurationProvider
rename web.config App.config
DPAPI might be a solution.
You can connect your usr/pwd/credentials to the machine. JGalloway knows more about this than I. JGalloway knows more about anything dotnet than I.
http://weblogs.asp.net/jgalloway/archive/2008/04/13/encrypting-passwords-in-a-net-app-config-file.aspx
If I haven't mixed things up this creates a usr/pwd combination that is bound to the very hardware of the machine. I.e. change network card and stuff might break. Also; one cannot create the usr/pwd/creds one machine and then transfer to another. In short this means that you have to do whatever you have to do on the production machine - might give you a headache if you are targeting continuous delivery.
Caveat: I haven't tried it myself. Instead I opted for a "regular" encryption. If someone got hold of my encrypted string and bytecode and reverse engineered it I would be smoked. But it was enough of security for me.