Browse DevX
Sign up for e-mail newsletters from DevX


Cryptography the .NET Way : Page 5

The .NET Framework classes for cryptography don't require you to become an expert mathematician or a cryptography guru. You'll find symmetric and asymmetric cryptographic providers as well as hash providers. Some of these provider classes end up calling into the unmanaged CryptoAPI library while other parts of the .NET cryptography solution are purely managed code.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Encryption in ASP.NET
The ASP.NET Framework uses different forms of encryption in various contexts. In particular, the view state of Web pages is normally hashed to detect tampering. In addition, when ASP.NET impersonates a fixed account, the user ID and password of the chosen identity can be encrypted and stored in the system registry. ASP.NET automatically encrypts the contents of the cookie it uses for forms authentication. Let's review these three aspects of how ASP.NET uses encryption in more detail.
You use the instance of the CryptoStream class as you would do with any other Stream class.
The view state of a page is the serialized state of the page's child controls. The information is stored in a hidden field and carried back and forth between the Web server and the browser. When the page posts back, the view state is retrieved from the hidden field and used to restore the state from which the original page originated. Even from this concise description, a fact emerges clearly: The view state is a potential vehicle of infection for the Web server. What if a malicious user modifies the contents of the view state? The view state is Base64 encoded but even that is weak protection. So ASP.NET digitally signs the serialized content of the view state by appending a hash code computed on it. This digital signature is a 20-byte string which is then Base64 encoded with the remainder of the view state. Such a form of protection effectively prevents tampering but can't guarantee confidentiality. To provide for that you should use HTTP over secure, but encrypted, sockets (HTTPS).

By default, ASP.NET works with impersonation turned off and all the pages run under the ASP.NET worker process account. To impersonate a particular user, though, you must indicate their user ID and password within a configuration file—typically, web.config. A configuration file is made of clear (unencrypted) text and resides within the application's Web space—an area of disk space more exposed to the risk of malicious attacks. Can you store sensitive information such as user ID and password in an encrypted form? Starting with ASP.NET 1.1, this is possible thanks to the services of the aspnet_setreg utility. The utility employs the Win32 API function CryptProtectData to encrypt the input information. It writes the binary text to the registry to a path decided by the code. In the web.config file only the registry path is written. To recover the credentials of the user to impersonate, an attacker must be able to execute the Win32 API CryptUnprotectData with the same logon credential as the encrypter and on the same Web server machine. ASP.NET bases its forms authentication on an encrypted cookie that it creates once the user's credentials are recognized by the HTTP runtime. Forms authentication works by redirecting unauthenticated users to a login page. After the credentials have been entered, ASP.NET validates the credentials and creates the cookie with a default timeout of 30 minutes. Next, ASP.NET redirects the request back to the original page. Next time, when IIS processes the request, it finds the cookie with the user's credentials and makes the request pass the security checkpoint. The cookie encryption is requested in the <forms> section of the web.config file and it uses the DES algorithm to encrypt the authentication ticket contained in the cookie. Note that the modified cookie is still subject to plain text modifications. In this particular context, encryption is really effective only if accompanied with hash validation. When the forms authentication protection settings require both encryption and validation, the ticket is encrypted and a hash is computed on it. ASP.NET appends the hash value to the cookie and uses it to verify that the original ticket has not been tampered with along the way.

Communication over networks is too often susceptible to unwanted reading or unauthorized spying. Cryptography—the art of data camouflage—is the technique that saves from such troubled waters. Cryptography has many facets. You can use cryptography to encrypt and decrypt disk files as well as dynamically and transparently scramble data traveling over network channels. In doing so, you make potentially unsecure channels inherently more secure, thus providing data integrity and authentication.

The .NET Framework's cryptographic classes manage many details of cryptography for you so you don't have to be an algorithm expert or a mathematician. Some of .NET's cryptographic classes are simply wrappers for the Win32 CryptoAPI set of libraries, while others are made of pure managed code. You can encrypt data using symmetric and asymmetric algorithms. For symmetric algorithms in particular—probably the most common case in end user applications—.NET provides an extremely handy facility called the CryptoStream class. Encryption is not just exposed as a programmable feature—the .NET Framework uses it internally. ASP.NET, a key subset of the .NET Framework, exposes good cryptographic tools for you to use.

Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant based in Rome, Italy. A speaker at many industry events including TechEd and DevConnections, Dino is the author of Building Web Solutions with ASP.NET and ADO.NET as well as Programming ASP.NET, both for Microsoft Press. You can reach him at dinoe@wintellect.com.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date