 |
|
|
 |
|
 |
didn't work for me, full of bugs.
|
|
|
|
 |
|
 |
Excellent,thank you sir,I could use it to protect my infomation
|
|
|
|
 |
|
 |
I was your student in Iran and now I work in one of the most favourite company in Canada. I always use your comments. Thanks for everything, I have learnt a lot from you.
|
|
|
|
 |
|
|
 |
|
 |
Hi,
Thanks for the article. I may be missing something but this seems unsecure (whether you declare your method as public or not). We're not specifying a key for the encryption so what key is this using? It does not seem very private when you can just run aspnet_iisreg -pdf to decrypt your configuration file.
On a side note you can also use aspnet_iisreg -pef to accomplish the same thing as the code above.
|
|
|
|
 |
|
 |
Hey xr,
The security provided by encrypting web.config is experienced, primarily in the following ways:
1. By preventing external users from seeing private information in web.config files that are exposed to the public (usually unintentionally).
2. This helps prevent leakage of information through privileged users who are basically honest.
In the first case, a common scenario is when the web.config is updated, sometimes, inexperienced administrators will backup the old configuration file with a name like web.config.old. or .bak or something like that. A malicious user will often try out these types of variations, since these are not (or at least weren't) hidden by IIS. This would give them a text file showing them many of the configuration settings.
As for people who have direct access to the computer/server where the web.config resides, it is actually quite easy to decrypt this information. Ideally, the only people who have access to these files are people who are authorized to view them. In any case, it is still helpful to have that extra layer of protection that prevents these users from seeing the userName and password combinations for static accounts. Even though, they could get the information if they wanted to, as a general rule, they don't have to see that information if they are in the configuration file, modifying non sensitive values. If a malicious user were to try to get them to divulge sensitive information that normally resides in web.config, chances are that information would be unknown, and the process necessary to get that information might take just enough effort to wake them up to what's happening.
Make no mistake, many malicious users are experts at social engineering and can often, easily get sensitive information from people who are not paying attention. Adding that extra layer of security can help to minimize the risk a little.
By the way, the key is generally created automatically on whatever the machine the web site is running on. It is possible to generate specific keys for combinations of the machine, user or website on any given machine, and these can be set to behave a certain way within the machine.config file, or even influenced (to some extent) in the web.config files themselves.
By default, a web.config that is encrypted on one machine cannot be decrypted on a different machine. It is possible to have a key that is shared across multiple machines so that web.config files can be copied without decrypting them first.
I don't recall, but I believe the same key is, or can be, used for encrypting the user tokens when a user authenticates to a particular web site. This is where a shared key can be more beneficial, since a user may move from one server to another in a web farm. When they are logged into a web site it would be necessary for the other servers to be able to determine if the user is already logged in or not.
I hope this information is useful
|
|
|
|
 |
|
 |
Can not be declassified
f***!!
value="y7gSjVQTKVBxIXgOQEw35l2RigS7eVrEUQ7rrUBOXalWHMHjm6L4faqmR2suT4FQVDV7G2Wetnw9/v9MDc7LrRwBvAQfUSLnPJq7ZkdOdA/1lbxK/TUG+d0Zx1Tyork2jrFOdDXcxIAHko9BY1ihjoZ5TBshgzYQ411AGo4pEZ/O1hyvZ1Odc1xAATOkzeJ5"
|
|
|
|
 |
|
 |
I would like to encrypt the appSetting section in app.config after it installed the live server. I Would you tell me how to do it?
|
|
|
|
 |
|
 |
You may also be interested in looking at the following, related Code Project articles:
Generic SymmetricAlgorithm Helper[^]
This is a generic helper class that exposes simplified Encrypt and Decrypt functionality for strings, byte arrays and streams for any SymmetricAlgorithm derivative (DES, RC2, Rijndael, TripleDES, etc.).
Making TripleDES Simple in VB.NET and C#[^]
This is a simple wrapper class that provides an easy interface for encrypting and decrypting byte arrays and strings using the 3DES algorithm.
|
|
|
|
 |
|
 |
Caution to everyone out there, This very well could be a social engineering exploit.
If not by the Author, then somebody else.
Don't use this class VERBATIM.
Just Use the technique, if you must.
Realize that a public Static class can be accessed easily from outside your program.
..and that any code you get off the web pertaining to security, could be a scam.
My apologies to the author, for any offense.
Where there's smoke, there's a Blue Screen of death.
|
|
|
|
 |
|
 |
Hi Dear; Tanx for your note...
It's ok that everybody use this class with no Static keyword and If thay want to use this methods, just create a object such as: Utilities obj = new Utilities(); and then use this methods.
Best Regards
Dariush Tasdighi
Dariush Tasdighi
http://www.IranianExperts.com Web Master
|
|
|
|
 |
|
 |
Static is ok, its the Public scoping that can get you in trouble.
If you want it to be "Public" inside your application, then declare it Internal Static.
The last thing you need is to lock the door to your Web.Config, then leave the window open.
Where there's smoke, there's a Blue Screen of death.
|
|
|
|
 |
|
|
 |
|
 |
Hello Dear;
I saw this arricle, But my article is absolutly different with it!
My article is about .NET 2.0 features and your article is about .NET 1.0/1.1 features.
Regards
Dariush Tasdighi
Dariush Tasdighi
http://www.IranianExperts.com Web Master
|
|
|
|
 |