Introduction
In the previous release of ASP.NET, the page developer could turn encryption on and off at the application level through a config setting. When validation was set to 3DES, ViewState was encrypted before being rendered in the page.
<configuration>
<system.web>
<machineKey validation="3DES" />
</system.web>
</configuration>
Main
In ASP.NET 2.0 the support for controlling and utilizing encryption has been expanded. Encryption settings can now be controlled separately for each page. In addition, the controls on the page can request that encryption be used for the ViewState, but even this request can be overridden by the page setting. The ViewStateEncryptionMode enumeration has three values: Auto, Always, and Never. The default value is Auto.
- ViewStateEncryptionMode.Auto
In this mode, ASP.NET will encrypt the ViewState for a page if any control on the page requests it. Note that this means all of the ViewState is encrypted, not just the ViewState for the control that requests it. A large part of the performance cost associated with encryption is in the overhead. So encrypting the whole ViewState is faster than doing separate encryption operations if more than one control makes the request.
- ViewStateEncryptionMode.Never
As you would expect, in this mode ASP.NET will not encrypt the ViewState, even if the application is set for encryption and controls on the page have requested it. If you know that no data involved in the page needs to be encrypted, then it may be safe to set the mode to Never. However, at this point it is rare for the documentation about a control to disclose what is being saved in ViewState, so you will want to be careful if there is a chance that sensitive data could be exposed.
- ViewStateEncryptionMode.Always
In this mode, ASP.NET does not wait for a control in the page to request encryption. ViewState is always encrypted. When working with sensitive data, it is a good practice to utilize encryption.
The mode is a property on page, but is set using either a page directive or in the web.config file for the application.
<%@Page ViewStateEncryptionMode="Always" %>
Or
<configuration>
<system.web>
<pages ViewStateEncryptionMode="Always" />
</system.web>
</configuration>
It is simple for someone writing a custom control to request ViewState encryption. The name of the Page method to call is
RegisterRequiresViewStateEncryption.
protected override void OnInit(EventArgs e) {
base.OnInit(e);
if(Page != null) {
Page.RegisterRequiresViewStateEncryption();
}
}
Control developers should be aware of the overhead and potential perf implications of using encryption, and should not take the decision to request encryption lightly. Notice that we refer to it as a request, even though the API name sounds like it is a mandate. If the control developers somehow know that the data being stored in
ViewState must be encrypted, they could add code to throw an exception in the case that the page developer turns encryption off.
protected override void SaveViewState() {
if(Page != null) {
if(Page.ViewStateEncryptionMode == ViewStateEncryptionMode.Never) {
throw new Exception(“ViewStateEncryptionMode.Never not allowed when using the SensitiveDataList control.");
}
}
}
Conclusion
To reduce the chance of someone intercepting the information stored in the ViewState, it is good design to encrypt the ViewState. You could do this in previous releases of ASP.NET, but the support for encryption has been improved in ASP.NET 2.0, allowing you to set this on a page-by-page basis.