FormsAuthentication.SetAuthCookie vs FormsAuthentication.Encrypt

Question # 1: Is setAuthCookie less secure than FormsAuthentication.Encrypt (ticketVariable)?

I mean, if someone tries to change the cookie created by setAuthCookie by changing the username, I assume this will break the authentication on subsequent calls?

Question No. 2: for those who use iphones and tablets to access the site, I believe that FormsAuthentication will fail? Given that I don’t want to use the cookieless option, is there another way to make the site safe for both smartphone web browsers and ummm web browsers without smartphones?

amuses

+6
source share
1 answer

SetAuthCookie basically creates a new FormsAuthenticationTicket with the specified username and persistence parameters, serializes it, FormsAuthentication.Encrypt () and sets it in the Response.Cookies collection. SetAuthCookie and GetAuthCookie both call FormsAuthentication.Encrypt indirectly.

On subsequent requests, the FormsAuthentiationModule module processes the AuthenticateRequest event. If it sees a cookie (it may have expired), it tries to decrypt its value with machineKey (it may have changed) and deserialize it back to FormsAuthenticationTicket (it may be corrupted). If none of this (bad things) happens, the ticket contains the username, release date, expiration information, etc. If the ticket has not expired, IIdentity and IPrincipal are created and assigned to HttpContext.Current.User and Thread. CurrentThread.Principal. In .NET 4.5 and later (I think) this is based on claims (ClaimsIdentity, ClaimsPrincipal). Before that I was thinking (GenericPrincipal, FormsIdentity).

Any intervention on the side of the user will result in the request being processed as anonymous. He will not be able to decrypt. The only thing that could compromise this check would be if the Key machine in the web.config / machine.config file somehow fell into the hands of the attacker or if there was an error in the framework code (Padding Oracle search for a historical example of this).

Other than that, another thing to look out for is session capture. If someone steals your cookie on public wifi, for example, he can transfer it to the server, and the server will behave as if it were you. This is usually due to sniffing network traffic. For these reasons, it is best to use SSL for your entire site and set the cookie only on HTTP and Secure (only via https connections) in web.config / system.web / authorization / forms. HTTP only means that it will not be available for client side Javascript. Only HTTP and Secure effectively mean only HTTPS. This will only work if you use SSL on your site.

FormsAuthentication works great in mobile web browsers. It just requires the client to accept cookies. As far as I know, all mobile devices will allow this.

+15
source

All Articles