Security via <machineKey> in ASP.NET 2.0


Secure ASP.NET




Security via <machineKey> in ASP.NET 2.0


By Don Kiely


One of the best features provided by the infrastructure of ASP.NET is security, which saves a lot of development effort repeatedly implementing security features for each application. One of the ways that it provides security is through encryption and hashing of various bits of sensitive information that comprise a typical Web site. Microsoft greatly expanded the options in ASP.NET 2.0, so it is worthwhile taking the time to understand how it protects your data by default and what options you have to adjust to meet your application needs.


ASP.NET 2.0 can protect several kinds of sensitive data in a Web application:

  • View state is tamper proof by default through hashing and can optionally be encrypted by setting the viewStateEncryptionMode attribute of either the @Page directive in a page or the <pages> element in machine.config.
  • Forms authentication cookies are by default both tamper proof and encrypted. Cookieless forms authentication tickets can also be protected.
  • Out-of-process session state identification is tamper proof.
  • Role manager cookies are both tamper proof and encrypted.
  • Anonymous identification cookies are tamper proof by default and can be encrypted.
  • The Membership systems passwords are stored by default as hashes and optionally encrypted.


As indicated by the list above, ASP.NET can protect data either by making it tamper proof or by encrypting it, or both. As with all security decisions, you need to provide the protection that is appropriate for the real threats to your site and data and not go overboard in inappropriate ways. Using hashing, you can make your data tamper proof if a threat involves unauthorized messing with the data, changing it to meet some nefarious purpose of a hacker. This is a bit of a misnomer though, because the use of the hash doesn t prevent tampering. Instead, it provides evidence or proof that the data was messed with, since the hash of the existing data no longer matches the hash ASP.NET creates and attaches to the data. In this context, validation refers to making data tamper proof through hashing the data and storing that value with the data. If you cannot allow the data even to be viewed by unauthorized people or processes, then you should encrypt the data.


All these hashes and encryption use the keys and other settings specified in the machineKey element in machine.config. The syntax for machineKey has been expanded in ASP.NET 2.0 and is deceptively straightforward:



  validationKey="AutoGenerate | value[, IsolateApps]"

  decryptionKey="AutoGenerate | value[, IsolateApps]"

  validation="[SHA1 | MD5 | 3DES]"

  decryption="[Auto | AES | 3DES]"



The configuration files in .NET 2.0 were cleaned up a bit, so machine.config no longer includes elements that are set at their default settings. This means that in a default installation of .NET 2.0 you won t find it in the default machine.config. But each of the attributes has a default, so this is the effective setting until you add the element to the config file and change the value of any of the attributes:









There is nothing complicated about this syntax, although the attribute names are not the most descriptive for their actual purpose. The validationKey specifies the key used for the hashing algorithm used to validate data. The decryptionKey, despite its name, is the key used to encrypt and decrypt data that you want to keep secret, such as when you set the viewStateEncryptionMode to either Auto or Always in an @Page directive.


By default, both validationKey and encryptionKey are set to AutoGenerate,IsolateApps. AutoGenerate means that the system takes care of generating a secure, cryptographically random key for you and saves it. In IIS 5.x, it is saved in the server s LSA, the Windows Local Security Authority. LSA is a very secure location for storing such things deep within the bowels of Windows. In IIS 6, it is saved in a protected section of the registry, since saving to LSA requires SYSTEM privileges that the IIS 6 process doesn t have. The IsolateApps modifier means that each application on the server gets its own key based on the application ID, which contributes toward the isolation of each application.


If you insist that you can do a better job of generating a key, or if you need to share a key across servers in a Web farm, you can specify your own key for either or both attributes. Make sure that you use the maximum possible length for the keys to get the maximum protection. See the documentation for machineKey for details about maximum key lengths.


The validation and decryption attributes specify the hashing and encryption algorithms used to protect data. The decryption attribute is a new addition in ASP.NET 2.0 to reduce the overloading of the older version of the validation attribute. The Auto option for this attribute uses an algorithm that is inferred from the key size. Triple DES encryption is the default, but a key of 128 or 256 bits will use AES. Despite the name, the decryption attribute applies to both encryption and decryption of data. Contrary to the documentation, you can use the Message Digest 5 (MD5) algorithm for the validation key in addition to SHA1, AES, and 2DES.


You can override the <machineKey> settings for an individual Web application by putting the key in the application s web.config file. This is particularly useful if you need to manually provide keys for a single application on the server. You can t, however, further override them in a subdirectory because you can only have a single key for each application.


Most of the uses of machineKey to protect various kinds of application data and settings have their own configuration options, and there can be subtle interactions with how you configure machineKey. ASP.NET provides many of the tools developers need to build secure sites, so it is worthwhile to take the time to get to know them.




Don Kiely, MVP, MCSD, is a senior technology consultant, building custom applications as well as providing business and technology consulting services. His development work involves tools such as SQL Server, Visual Basic, C#, ASP.NET, and Microsoft Office. He writes regularly for several trade journals, and trains developers in database and .NET technologies. You can reach Don at mailto:[email protected] and read his blog at





Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.