问题 #1：setAuthCookie 是否比 FormsAuthentication.Encrypt(ticketVariable) 更不安全？
我的意思是，如果有人试图通过修改用户名来修改 setAuthCookie 创建的 cookie，我想这会违反后续调用的身份验证吗？
问题 #2：对于那些使用 iphone 和平板电脑访问网站的人，我想 FormsAuthentication 会失败吗？鉴于我不想使用 cookieless 选项，是否有另一种方法可以使网站在智能手机网络浏览器和 ummm 非智能手机网络浏览器上都安全？
干杯
SetAuthCookie 基本上使用提供的用户名和持久性选项创建一个新的 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，并在 web.config/system.web/authorization/forms 中将 cookie 设置为仅 HTTP 和安全（仅通过 https 连接呈现）。HTTP 仅意味着它对客户端 Javascript 不可用。HTTP Only and Secure 实际上意味着仅 HTTPS。这仅在您在整个站点上使用 SSL 时才有效。
FormsAuthentication 可以在移动网络浏览器上正常工作。它只要求客户端接受 cookie。据我所知，所有移动设备都允许这样做。