title: Any reason not to trust ASP.NET AntiForgeryToken?
body: <p>I know that Stack Exchange sites do not use the ASP.NET MVC built-in <code>@Html.AntiForgeryToken()</code> for the prevention of XSRF/CSRF attacks. Instead of creating a hidden input named <code>__RequestVerificationToken</code> with a <em>really long</em> value based on the machineKey section of the web.config, the Stack Exchange method creates an input named <code>fkey</code> with a <em>MUCH</em> more succinct value. This is apparently a Guid, and based on evidence from the <a href="http://code.google.com/p/stack-exchange-data-explorer/" rel="noreferrer">Stack Exchange Data Explorer project on Google Code</a>, this value is tied to each individual user, remaining fairly constant until you log in or out.</p>
  
  <p>Also, the Stack Exchange value is constant on a page, and is made available to client script, so that Ajax posts for voting and things like that also use the token. By contrast</p>
  
  <p>So why does Stack Exchange march to its own drummer?</p>
  
  <ul>
  <li>Is there a reason not to trust AntiForgeryToken?</li>
  <li>Does the AntiForgeryToken have some limitations that the Stack Exchange team was unwilling to accept? If so what were they?</li>
  <li>Or maybe AntiForgeryToken just wasn't around (it started life in the MVC Futures project) when Stack Overflow was started, and if they had it to do over from scratch today they would use AntiForgeryToken?</li>
  </ul>
  
  <p>I've been unable to find any blog posts from Jeff or others on the Stack Exchange team to explain the guiding principles behind how the XSRF-prevention policy on the SE network. It would be really nice if one of them could do a write-up, assuming of course that it could be done in general terms without creating a vulnerability.  It would be really valuable information for those of us that want to make our websites secure, but aren't entirely comfortable just blindly trusting Microsoft to do it for us.</p>