ASP.NET VERSIONS: ALL
By Don Kiely
Encryption is the key to much of the security in today s application software on any platform. One of the major benefits of ASP.NET and the .NET Framework is its support for the encryption infrastructure, both in terms of implementing a variety of encryption and hashing algorithms as well as support for protecting data internally. Best of all, it often manages keys for us. This is a huge benefit because key management is the hardest thing about encryption to get right: keeping secrets secret.
One of the places where ASP.NET takes care of all the details for developers is in the machineKey element in machine.config. The docs say that the key configures keys to use for encryption and decryption of forms authentication cookie data and view state data, and for verification of out-of-process session state identification. Because of this feature, the authentication information saved to the browser cookie either in-memory or persisted is reasonably protected from theft or abuse from an attacker if you use ASP.NET forms authentication. It also means that if you set enableViewStateMAC to true to encrypt ViewState (rather than the default, which is to simply base64 encode ViewState data) .NET will manage the key for you, and you don t have to include any code to handle the encryption or decryption of the data.
Here s the syntax for the element:
Although you can specify a hexadecimal value 40 to 128 characters long for the validation and decryption keys, the attributes are set to AutoGenerate by default. You can override the keys at the machine, site, and application levels, but not in any subdirectories of your application. The IsolateApps option tells ASP.NET to use separate keys for each application on that machine, and the validation attribute specifies the encryption algorithm to use. You don t always get what you want, so check the documentation for machineKey for the details on what you get when you specify SHA1, MD5, and 3DES.
What s interesting here is that when you specify AutoGenerate, the random key that is generated is stored in the Local Security Authority (LSA). LSA is a Windows service that pretty much manages all the security on the local system, including logging in and authenticating users, as well as all the information contained in the local security policy. You can store your own secrets in LSA, but there are a couple of disadvantages:
- The process storing the secret must have administrative privileges, because monkeying with LSA is a highly sensitive matter.
- LSA has only a limited number of secret storage slots, a lot of which are already used by Windows.
By the way, LSA is distinct from the Data Protection API (DPAPI). DPAPI uses LSA in the process of encrypting data, but the DPAPI keys are not stored in LSA.
The .NET documentation for machineKey states that the auto-generated keys are stored in LSA. That s true most of the time, but only if the process security context doesn t have administrative privileges and therefore cannot directly access LSA, wherein the key is stored in the registry instead. You can find the AutoGenKey named value under the HKEY_CURRENT_USER\Software\Microsoft\ASP.NET key, encrypted using DPAPI. In the relatively secure IIS 6 that means that most of the time the key is stored in the registry rather than LSA, but in earlier versions it is probably more often saved in LSA.
My thanks to fellow Visual Developer-Security MVP Valery Pryamikov for pointing out that the auto-generated machine key is not always stored in LSA and that the documentation fails to mention that fact. Valery has a great .NET security blog that is must-reading if you want to develop secure .NET applications: http://www.harper.no/valery/.
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 http://www.sqljunkies.com/weblog/donkiely/.