You already know this, somewhere in the back of your mind your little inner voice keeps telling you that you shouldn’t be putting into ViewState anything that’s even remotely close to looking as if it could ever be sensitive.
Although ViewState provides some built in mechanisms to prevent tampering and hijacking (via Machine Authentication Check, know as MAC), and is very useful to developers, the thing to remember is that it is completely readable text, stored on the client’s browser, in the markup of the page.
What do you mean “completely readable”? I mean just that, it’s a base 64 encoded string that is easily decoded into human (or hacker software) readable. To see for yourself just download and use the ViewState Decoder, available from the awesome guys at PluralSite (http://www.pluralsight-training.net/community/media/p/51688.aspx ).
It’s not uncommon to store custom items in ViewState, while this can be extremely useful it’s important to remember that this information will be packaged up into the Base 64 encoded string (ultimately ended up as the Value of a Hidden Field) and easily viewable to the world with little effort.
If you don’t need ViewState then turn it off. This is easily accomplished at the control and/or page level or globally via the Web.config file (a.k.a. ViewStateEnabled = “false”). To learn more about ViewState please visit http://msdn.microsoft.com/en-us/library/ms972976.aspx pay special attention to the section about ViewStateMAC and Server.Transer, read the KB Article which explain in detail the security whole you open up when disabling the ViewStateMAC security feature (http://support.microsoft.com/default.aspx?scid=kb;EN-US;316920 )
An important thing to remember is that ViewState can grow to be extremely large, bloating the page size that must be downloaded to the end users computer both on the initial visit to the page and with each postback, resulting in slower site performance and heavier loads on the server and network.