Week-09

=Week-09=

How to: Secure Connection Strings When Using Data Source Controls
When working with data source controls it is recommended that you centralize the location of your connection strings by storing them in the application's Web.config file. This simplifies the management of connection strings by making them available to all of the ASP.NET pages in a Web application. In addition, you do not need to modify numerous individual pages if your connection string information changes. Finally, you can improve the security of sensitive information stored in a connection string, such as the database name, user name, password, and so on, by encrypting the connection string section of the Web.config file using protected configuration.

To encrypt connection string information stored in the Web.config file,
 * 1) At the Windows command line, run the ASP.NET IIS registration tool (aspnet_regiis.exe) with the following options (The aspnet_regiis.exe tool is located in the %systemroot%\Microsoft.NET\Framework\versionNumber folder.): (1) The -pe option, passing it the string "connectionStrings" to encrypt the connectionStrings element. (2) The -app option, passing it the name of your application.
 * 2) Determine the user account or identity under which ASP.NET runs by retrieving the current WindowsIdentity name.
 * 3) At the command prompt, run the aspnet_regiis.exe tool with the following options: (1) The -pa option, passing it the name of the RSA key container for the default RsaProtectedConfigurationProvider. (2) The identity of your ASP.Net application, as determined in the preceding step.
 * 4) To decrypt the encrypted Web.config file contents, run the aspnet_regiis.exe tool with the -pd option. The syntax is the same as encrypting Web.config file contents with the -pe option except that you do not specify a protected configuration provider. The appropriate provider is identified in the configProtectionProvider attribute for the protected section.

More Information

In general terms, explain how secure connections work.
The Secure Socket Layer protocol was created by Netscape to ensure secure transactions between web servers and browsers. The protocol uses a third party, a Certificate Authority (CA), to identify one end or both end of the transactions. This is in short how it works.


 * 1) A browser requests a secure page (usually https://).
 * 2) The web server sends its public key with its certificate.
 * 3) The browser checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted.
 * 4) The browser then uses the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted http data.
 * 5) The web server decrypts the symmetric encryption key using its private key and uses the symmetric key to decrypt the URL and http data.
 * 6) The web server sends back the requested html document and http data encrypted with the symmetric key.

More Information

The browser decrypts the http data and html document using the symmetric key and displays the information. In general terms, explain how digital secure certificates work.

Explain how the strength of a digital secure certificate affects its level of security. Describe the difference between a single root certificate and a chained root certificate. Describe the functions that are provided by the IIS Certificate Wizard for working with digital certificates.