.NET 4.5 brings a lot of improvements in how Cryptography is handled within ASP.NET, with new APIs Protect and Unprotect and various under-the-hood changes. Levi Broderick explains the motivation, the changes and compatibility in a series of articles.
ASP.NET needs two secret hash keys for crypto – decryption key and validation key – this pair is together called a machine key. The machine key is reused between different components. Levi’s first article shows how this .NET 4.0 design can lead to security issues in one component have a much bigger impact on other components of the system as well.
Similarly the MachineKey.Encode and Decode APIs available to the developers also use the same machine key for encryption. Hence, developers can further introduce their own security issues that can again have a cascading effect.
Most of these concerns (and some others) were highlighted in an IEEE paper by Duong and Rizo; although the exploits shown in the paper were addressed, some of the key concerns they highlighted remained.
As a solution, .NET 4.5 introduces the following changes -
- The transformation applied to machine key is now very different – the machine key with few bits changed is used as a key-derivation-key in a key definition function which generates the key that the application actually uses
- New Protect and Unprotect APIs which combine MACing and encrypting into a single step called “protecting”. The Encode and Decode APIs are still available but are deprecated.
- Introduction of “purpose” parameter which can isolate a particular consumer of the encryption APIs from others which is used for further strengthening the encryption – and making it less vulnerable to security issues found in other areas
These changes are not enabled as default behaviour and have to be explicitly enabled in the web config (this is done in all the new ASP.NET project templates). All these changes are described in detail in the second article. The third article goes into advanced usage scenarios and several notes to keep in mind.
Note that the password hashing in membership providers are not handled in this change and were handled separately.