I've a dataconfiguration.config encrypted file for an application on ASP.NET Framework 3.5
I need to change my connection string, how can i decrypted and read this file?
Security it's not an issue, I'm on a development enviroment.
Any tip will be preciated.
Thanks.
A common way to encrypt ASP.NET configuration sections (such as ConnectionStrings) is to use Protected Configuration. However if your file does not read as XML, this method was not used or was not the only level of encryption used. It sounds like maybe there was a third party tool involved.
If I were you, I would probably create a new config file, and find everywhere in the project the old config file was referenced to point things at the new file.
If that is not possible, maybe you'd have better luck posting a question in a general cryptography category or doing some searches on the subject. I know some encryption can be identified by look at the encrypted data. Some encryption schemes are designed specifically to hide that though. Good luck.
Related
I currently have an ASP.NET website that has an encrypted connection string within it's web.config file. The settings are in the general AppSettings section, not the ConnectionString section. Within the application code we manually decrypt the connection string at run time as needed.
While working on refactoring the site, I came across a method that Microsoft once suggested which involves running an aspnet_regiis command in order to insert encrypted data directly into the ConnectionString section of the web.config file. This suggested method is now considered Retired Content although it doesn't say why (other than a small reference that some of the links may no longer be valid).
Here's the site I'm referring to:
How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI
My questions are basically - Should I bother refactoring the existing functionality to use Microsoft's once recommended way? I believe it would be more efficient than the current process. Also, why would this method be considered Retired Content? Is there a better way to do this, rather than my site supporting the encrypt/decrypt methods?
I've search Google & StackOverflow for other ways of doing this, but they all seem refer to Microsoft's way - or the way I currently have it implemented.
Maybe the site/doc you're referring to is marked as obsolete, but the technology behind is not. Here are the official links, not marked as obsolete:
DpapiProtectedConfigurationProvider Class (with an example), there is also the RsaProtectedConfigurationProvider that is capable of encrypting sections
Encrypting Configuration Information Using Protected Configuration
Encrypting and Decrypting Configuration Sections
ASP.NET IIS Registration Tool (Aspnet_regiis.exe) with the -pe option
I would definitely use this technology.
I'm guessing that they say the documentation is considered retired content because it was written for the .NET 2.0 framework. That being said, as Simon said, the technology behind it is still good to use.
The nice thing about using aspnet_regiis to encrypt your web.config file is that it is transparent to the application. You can write your logic assuming that the appSettings or connectionStrings sections are not encrypted, and if they are are encrypted using this method the .NET framework will take care of decrypting them before giving you the value.
One thing to keep in mind with using this method is that it will encrypt the entire appSettings section. If you open your web.config once it's encrypted you will not see any of the keys, but just a big encrypted hunk of data.
I want to encrypt the files that are uploaded by users of a web application.
The files need to be encrypted and decrypted individually.
Are there advantages to encrypting the file using an external tool than inside the application?
For example calling gpg, crypt or 7zip (or any other tool) immediately after a file was uploaded.
Upon request for a retrieval, call them again to decrypt, then serve the file.
I thought this may have performance advantages as well as the fact that encryption can be outsourced to a potentially more robust and well trusted application than the library available in the programming language.
Launching an tool creates a new process every time, which can impact scalability. There are libraries as respectable as tools, some of them from the same codebase.
First of all, you shouldn't implement your own crypto. That said, the alternatives don't look that different to me. Surely you can use GPG either in-process (called via an API) or out-of-process (with parameters passed on the command line). Then the considerations come down to the usual engineering ones of performance, robustness, etc and really have nothing in particular to do with cryptography.
I seen some asp.net developers encrypt ConnectionStrings that was included in separate config file. Why they did that ? I know that config files are unreadable from the client side/browser! Is it possible to access to this kind of files ?
You can't rule out that the web box is compromised.
Also, you don't want the web admins to know passwords to databases.
You need to remember that config files cannot be obtained by the browser just because .config extension is in the list of restrictions in IIS metadata. It may be possible to get them from the server in other way or some misconfiguration problem may allow them to be downloaded.
They can be accessed by maintenance personnel, backup operators or others that have access to the disk without going through the website. That´s one example.
If you upload your web.config file with custom errors set to "off", any errors produced by your web application will display your code. This could even include lines from your config files and this could include the "ConnectionStrings" making them visible to the public.
To every organization the most important thing to them is their data
This is done where there are multiple developers working on the same
application
Sometimes, new developers are also enrolled in the team. Exposing each & every aspect of your database, system, login name, machine name is never a good approach
There is chance of information leak in production, testing Q/A phase etc.
This comes really handy when there is a code theft within an organization, atleaset your data is safe from an outside intrusion as the connection strings were encrypted
Can you bear the risk if someone has access to your database & perform a table/schema drop or a delete all from your tables?
MSDN: How to secure connection strings when using a datasource
As SWFs are notoriously easy to decompile, If I am distribution SWF with secure keys inside or some valuable peace of code, how should I secure it?
EDIT:
I think it is very easy to decompile SWF because it is byte coded to SWF and then jitted to run. This same happens with Java compilation and execution. Does this mean even java codes are not secure enough?
Why, then, Java is far more trusted and reliable and SWF is not considered secure anywhere?
The short answer is DON'T do that. Even with code obfuscation, or storing data in a byte array, there is NO WAY to prevent someone who is determined (and able) from getting anything and everything from your source.
What type of secure key are you trying to put into your swf? What will it be used for?
Key theft is probably out. If someone is dedicated to it, they will find a way, despite obfuscation, to get at the key.
Code protection & IP is another matter. Here obfuscation and "encryption" (i.e. whatever is done to prevent decompilers from functioning properly) are valid methods. If your code is sufficiently obfuscated it would be very hard for competitors to steal it or to learn too much about your code's internals. It's just not feasible. Heck, trying to learn someone else's code is hard enough as it is, and so trying to decipher code that looks like loc_12312++; if (loc_23423) loc_4345(); is just not worth anybody's time.
I strongly recommend that if you care about the IP in your application's design and internal workings, you use a tool like SecureSWF to obfuscate the code as much as you can. Unlike with license keys, here the protection isn't as weak as its weakest link - the more you obfuscate the harder you make it to steal your IP.
Edit
My experience with Flex obfuscation tools is that you have to tweak the obfuscation quite a lot to get what you need. Simply telling the obfuscation software to rename all variables, classes, etc. is bound to break your application, unless it's really really simple. So you have to choose which packages and classes to obfuscate and tweak various other parameters in order to get a working application.
Once it's obfuscated though, it's pretty hard to decipher, in my opinion. Here's a sample, just to get a perspective:
I'd rethink what you're putting in the SWF. But that said, if you see no other options, NitroLM has a SWF encrypter which allows you to encrypt the SWF. Sharify is an alternative service.
In theory you could write your own mechanism for encrypting a SWF and your own "EncryptedSWFLoader." Of course, I suspect that any key in the SWF will most likely be something you need to send back to a server; and having someone sniff the packets--with a tool such as ServiceCapture or Charles--is more likely to be a source of "key leakage" than decrypting the SWF.
You won't get real security, but to make decompilation a little harder, use a code obfuscation tool, like doSWF, and/or store important data as byte array.
Edit: Ignore this answer: didnt spot the 'distributing' part **
If run from a webserver you can store your secure key in a text file, and read this text file into the swf from an assets folder (using urlLoader). People wont be able to get to the assets if you dont set public permissions, and the decompiled swf wont have that value (will just have a variable name).
How is it being distributed?
I have a website about to go live. I'm wondering what I should be doing about the connectionstring in the web.config. Do I obfuscate it and it so how?
Thanks!
The standard method is to encrypt it. http://ondotnet.com/pub/a/dotnet/2005/02/15/encryptingconnstring.html
However, another good option is to store it in the registry and set the permissions so that only the asp.net runtime can access it.
See this article: http://msdn.microsoft.com/en-us/library/ff649224.aspx and this KB: http://support.microsoft.com/kb/821616
Although I do have to say that using the registry does tend to complicate deployment and using text/staging servers a bit. We did it... ONCE and then went back to encrypting.
You can encrypt the <connectionStrings> section in your web.config - see How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI
Here is an example for the same;
http://whatilearnttuday.blogspot.in/2012/02/use-of-configurationproviders-to.html
Since you didn't provide any information about this in your question I will assume you have credentials in your connection string.
From a security perspective you should try to avoid this, use Windows Authentication if possible. Obviously this requires that you have access to an Active Directory environment and all the servers are deployed in it.
If not, it's always better to lock down the web-server instead of trying to make sure that files on disk are secure from tampering by different users.
If even this is not possible then I would follow the approach given by the other replies, encrypting the sensitive content with DPAPI.
You could simply encrypt your entire web.config file:
See the steps here:
http://www.proworks.com/blog/archive/encrypting-your-webconfig/