问题＃1： setAuthCookie是否比FormsAuthentication.Encrypt（ticketVariable）更安全？
我的意思是，如果有人试图通过修改用户名来修改setAuthCookie创建的cookie，我想在后续调用中违反了身份验证？
问题＃2： 对于那些使用iphone和平板电脑访问网站的人，我认为FormsAuthentication会失败吗？鉴于我不想使用cookieless选项，是否还有另一种方法可以在智能手机网络浏览器和非智能手机网络浏览器上保护网站安全？
欢呼声
答案 0 :(得分：17)
SetAuthCookie基本上使用提供的用户名＆amp;创建一个新的FormsAuthenticationTicket。持久化选项，序列化它，FormsAuthentication.Encrypt（），并在Response.Cookies集合中设置它。 SetAuthCookie和GetAuthCookie都间接调用FormsAuthentication.Encrypt。
在后续请求中，FormsAuthentiationModule处理AuthenticateRequest事件。如果它看到一个cookie（它可能已经过期），它会尝试使用machineKey解密它的值（它可能已被篡改）并将其反序列化为FormsAuthenticationTicket（它可能已损坏）。如果没有（坏东西）发生，则票证包含用户名，发布日期，到期信息等。如果票证尚未过期，则创建IIdentity和IPrincipal并将其分配给HttpContext.Current.User和Thread。 CurrentThread.Principal。在.NET 4.5及更高版本（我认为）中，这是基于声明的（ClaimsIdentity，ClaimsPrincipal）。在此之前，我认为它是一个（GenericPrincipal，FormsIdentity）。
用户端的任何篡改都会导致请求被视为匿名。它将无法解密。唯一会影响此验证的事情是，如果web.config / machine.config中的machineKey以某种方式落入攻击者的手中，或者如果框架代码中存在错误（搜索Padding Oracle以获取此问题的历史示例） ）。
除此之外，需要注意的另一件事是会话劫持。例如，如果有人在公共wifi上窃取你的cookie，他们就可以将它呈现给服务器，服务器的行为就像是你一样。这通常涉及网络流量嗅探。出于这些原因，最佳做法是在整个站点中使用SSL，并将cookie设置为仅HTTP和Secure（仅通过https连接呈现）在web.config / system.web / authorization / forms中。 HTTP仅表示它不可用于客户端Javascript。 HTTP Only和Secure实际上仅指HTTPS。只有在整个网站上使用SSL时，此功能才有效。
FormsAuthentication在移动网络浏览器上运行良好。它只需要客户接受cookie。据我所知，所有移动设备都允许这样做。