ASP.NET Viewstate validation – ASP.NET 1.1 vs. ASP.NET 3.5

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.

Source: http://msdn.microsoft.com/en-us/library/aa479501.aspx

Well it depends. Invalid viewstate can happen for a variety of reasons.

1. Viewstate is too big and has not finished rendering before a user causes a postback on the page. The fix is generally to disable all controls that trigger postbacks and enable them client side once the page has finished loading - see http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate-mac-failed-error.aspx
2. You are using viewstate MACs (and you should be, for security reasons) but you have not set a machine key and the application pool has recycled generating a new one. Don't forget to set a ViewStateUserKey.
3. Someone is using an old version of IE on the mac where it truncates hidden form fields. In this case you'll need to move viewstate out of the page into session state.
4. Viewstate MAC issues generally indicate you're on a web farm and have forgotten to set a machine key in web.config. However if you have done this then it is probably someone trying to do bad things (bots posting comments, someone trying to trigger events for disabled controls etc.) The cause of these should be tracked down if only to rule out potential security issues.

Whatever you do do not turn off viewstate or event validation.