How does the MVC anti forgery token survive between web server restarts?

Question

I've implemented anti-forgery protection using the ValidateAntiForgeryTokenAttribute in MVC 5. It is working fine, but in the future we may move to more of a "web farm" approach to hosting. If I run my application in development and go to a form, restart the web server (by restarting the app in Visual Studio) and then submit a form, it doesn't throw the System.Web.Mvc.HttpAntiForgeryException.

Our application doesn't use any other session state. Can someone help me understand how my server picks up where it left off? I'm not defining a machineKey in my web.config, or anywhere else that I can find. Does it have something to do with running in a development environment?

The only references I can find to this are for earlier versions of MVC, so I'm wondering if this is solved in a different way now.

I'm glad this functionality works, but I need to understand why.

Answer 1

The server itself isn't remembering anything; it doesn't have to.

The two things at work here are:

• The form hidden input
• A cookie

This means that if the user visits a page with an AntiForgeryToken on it, then the server restarts, it's no problem because the user's and the form's __RequestVerificationToken are still the same as they were.

The actual security token is a hashed key that is stored inside the AntiForgeryToken object. This object is serialised to Base 64 and that is what you see when you look at the values of the __RequestVerificationToken. Since the security keys are stored each time, even if the server resets the values are still inside those objects. The keys are then retrieved and compared in order to validate the tokens.

There is no decryption during this process. The tokens are deserialised, the security keys read and then compared. Since the security keys are not encrypted, but are rather hashed, then they cannot be decrypted; only compared.