.NET Nuances

SecureASP.NET

LANGUAGES: ALL

ASP.NET VERSIONS: ALL

.NET Nuances

AutoGenerate Subtleties

By Don Kiely

Encryption is the key to much of the security in today sapplication software on any platform. One of the major benefits of ASP.NETand the .NET Framework is its support for the encryption infrastructure, bothin terms of implementing a variety of encryption and hashing algorithms as wellas support for protecting data internally. Best of all, it often manages keysfor us. This is a huge benefit because key management is the hardest thingabout encryption to get right: keeping secrets secret.

One of the places where ASP.NET takes care of all thedetails for developers is in the machineKey element in machine.config. The docssay that the key configures keys to use for encryption and decryption of formsauthentication cookie data and view state data, and for verification ofout-of-process session state identification. Because of this feature, theauthentication information saved to the browser cookie either in-memory orpersisted is reasonably protected from theft or abuse from an attacker if youuse ASP.NET forms authentication. It also means that if you setenableViewStateMAC to true to encrypt ViewState (rather than the default, whichis 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 decryptionof the data.

Here s the syntax for the element:

           decryptionKey="AutoGenerate|value[,IsolateApps]"            validation="SHA1|MD5|3DES"/>   Although you can specify a hexadecimal value 40 to 128characters long for the validation and decryption keys, the attributes are setto AutoGenerate by default. You can override the keys at the machine, site, andapplication levels, but not in any subdirectories of your application. TheIsolateApps option tells ASP.NET to use separate keys for each application onthat machine, and the validation attribute specifies the encryption algorithmto use. You don t always get what you want, so check the documentation formachineKey for the details on what you get when you specify SHA1, MD5, and3DES.   What s interesting here is that when you specifyAutoGenerate, the random key that is generated is stored in the Local SecurityAuthority (LSA). LSA is a Windows service that pretty much manages all thesecurity on the local system, including logging in and authenticating users, aswell as all the information contained in the local security policy. You canstore your own secrets in LSA, but there are a couple of disadvantages: The process storing the secret must haveadministrative privileges, because monkeying with LSA is a highly sensitivematter. LSA has only a limited number of secret storageslots, 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 keysare not stored in LSA.   The .NET documentation for machineKey states that the auto-generatedkeys 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 cannotdirectly access LSA, wherein the key is stored in the registry instead. You canfind the AutoGenKey named value under theHKEY_CURRENT_USERSoftwareMicrosoftASP.NET key, encrypted using DPAPI. In therelatively secure IIS 6 that means that most of the time the key is stored inthe registry rather than LSA, but in earlier versions it is probably more oftensaved in LSA.   My thanks to fellow Visual Developer-Security MVP ValeryPryamikov for pointing out that the auto-generated machine key is not alwaysstored in LSA and that the documentation fails to mention that fact. Valery hasa great .NET security blog that is must-reading if you want to develop secure.NET applications: http://www.harper.no/valery/.  DonKiely, MVP, MCSD, is a senior technology consultant, building customapplications 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 readhis blog at http://www.sqljunkies.com/weblog/donkiely/.