Secure Solutions to Validation of ViewState MAC Failed

Question

First off, I was finally able to track down my error. It turned out that I was actually managing to create a SQL Server deadlock which in turn meant that my .Net charts were throwing an un-handled NullReference Exception (derp).

All right, so, there are only a few alternatives to ViewState in ASP.NET. I finally got my page working, so I'm leaving this here for anyone who randomly happens across it.

One of the alternatives you see here on SO is to just set the machine key and enable the MAC State like so:

<pages enableViewStateMac="true">

and then:

<machineKey 
  validationKey="[128 Hex Number]"
  decryptionKey="[64 Hex Number" 
  validation="SHA1" 
  decryption="AES" />

I was moderately concerned about this for security reasons, but I couldn't make any other solution work. The conclusion I eventually came to was that I would just statically set it and re-generate the machine keys on a regular based on Microsoft's example code:

    static void Main(string[] argv)
    {
        //128 Hex characters for the validation key, 64 for the AES decryption key
        int hexLengthForEncryption = 128;

        string validationKey = Generate_New_Key(hexLengthForEncryption, argv);

        hexLengthForEncryption = 64;

        string decryptionKey = Generate_New_Key(hexLengthForEncryption, argv);

        string[] originalKeys = new string[2] {validationKey, decryptionKey};

        Generate_File(originalKeys);

        Console.WriteLine("The file has been generated. Would you like to generate new keys in a new file?");

        string yorn = Console.ReadLine();

        while ((yorn != "N") && (yorn != "n") && (yorn != "no") && (yorn != "No"))
        {               
            hexLengthForEncryption = 128;
            validationKey = Generate_New_Key(hexLengthForEncryption, argv);
            hexLengthForEncryption = 64;
            decryptionKey = Generate_New_Key(hexLengthForEncryption, argv);

            string[] freshLines = new string[2]{validationKey, decryptionKey};

            Generate_File(freshLines);

            Console.WriteLine("The file has been generated. Would you like to generate new keys to a new file?");

            yorn = Console.ReadLine();
        }
    }

This didn't totally solve my problem, though. What I ended up doing was, for the charts which have a lookup page, I added a try catch to my larger SQL queries and, despite reservations from posts like this and similar concerns with WITH(NOLOCK) on Stack Overflow, we decided that the possible pitfalls fell within acceptable error margin parameters.

In the page which actually cares about the Session ID, I had to force the program to halt briefly and return to the lookup page. Interestingly enough, it didn't crash at all with me logged out and the charts refreshing every two minutes over night. The page that doesn't use the Session ID still has a throw-away variable set like this on the main page:

    protected override void OnInit(EventArgs e)
    {
        base.OnInit(e);
        ViewStateUserKey = Session.SessionID;
    }

And this in the control for the solution to work properly:

        //This variable is necessary to having a session state persist across postbacks, but is otherwise useless
        Session["Throwaway"] = DateTime.Now;

The Catch on this page simply redirects back to itself. The one with a search page caused a reference loop problem as the session state (which the page relied on to generate the charts) was empty and therefore broke the charts. I don't know that this will help anyone, but both the charts which use session state and those which don't require it are finally working after a network upgrade. Cheers!