C# Where is the Authcookie set?

Question

When using FormsAuthentication, where is the Authcookie placed? On the server or on the client? And when the client has cookies disabled, does FormsAuthentication still work?

Answer 1

It's placed on the client, if you use firebug it should look something like this in the response: .ASPXFORMSAUTH=C8390F0E68890DF5C731DB2B.... Forms authentication can still work, but everything will be set in the browser's url. Decent documentation here

Answer 2

Cookies are always stored client-side.

Browsers that support cookies interpret the Set-Cookie HTTP Header (if cookies are enabled), parse the value of this header for details of the cookie to store (name, value, domain, path and expiry) and save the cookie value somewhere. For persistent cookies (i.e. those with an expiry value set) this location is typically somewhere on the file system, but the location is browser dependent. For session cookies (cookies without an expiry value that live as long as the browser is open) this is probably an in-memory data structure.

Answer 3

On the client. Supposedly cookieless is supported by changing the web.config, but I haven't had success in implementing it. If cookieless is used, the cookie is stored in the URI of the web page, such as http://MySite.com/MyWebApplication/F(XXXX))/home.aspx.

<forms 
   cookieless="[UseUri|UseCookie|AutoDetect|UseDeviceProfile]" 
</forms>

From forms Element for authentication (ASP.NET Settings Schema):

In AJAX-enabled ASP.NET Web sites, use the default value UseCookies for the cookieless attribute. Settings that use cookies encoded in the URL are not supported by the ASP.NET AJAX client-script libraries.

UseCookies Specifies that cookies will always be used, regardless of the device.

UseUri Specifies that cookies will never be used.

AutoDetect Specifies that cookies are used, if the device profile supports cookies; otherwise, cookies are not used. For desktop browsers that are known to support cookies, a probing mechanism will be used to try to use cookies, when enabled. If a device does not support cookies, no probing mechanism will be used.

UseDeviceProfile Specifies that cookies are used, if the browser supports cookies; otherwise, cookies are not used. For devices that support cookies, no attempt is made to probe to determine whether cookie support is enabled.

This attribute is new in the .NET Framework version 2.0.

The default is UseDeviceProfile.

Using cookieless can be less secure than requiring cookies. From Understand How the ASP.NET Cookieless Feature Works:

One big issue that is unique to the cookieless feature (not present when using cookies), is the vulnerability linked to users sending URLs to other users (via Email and IM, for example). When this feature is turned on, for, say, FormsAuthentication, and the user emails his (or her) URL to some other user, the second user will automatically log on to the server with the credentials of the first user. One countermeasure is to reduce the time-window in which this can happen, by reducing the cookie timeout for forms authentication (as described previously in point (b)).

Answer 4

To get a better understanding of this I would highly recommend using a Http analyzer like the HttpFox extension for FireFox. It allows you to see what cookies from authentication come across and are stored.

Answer 5

On the server. Use Reflector to dig into the FormsAuthentication class, and you can track down where the cookie is being initialized and set.

Reflector is a free tool that "decompiles" .NET assemblies, allowing you to see more or less what they are doing (although it doesn't show the original source code, just a reconstructed version based on the IL).

Using this, you can open up the file

c:\Windows\Microsoft.NET\Framework\<version>\System.Web.dll

and view the class FormsAuthentication in the System.Web.Security namespace. There, you can see that the cookie is created and set in the private overloaded method

GetAuthCookie(string userName, bool createPersistentCookie, string strCookiePath, bool hexEncodedTicket)

which is called by RedirectFromLoginPage (or by the public version of GetAuthCookie).

Studying this file, you can also see how .NET handles cookieless authentication.