问题一:
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 以获取此历史示例)。
除此之外，要注意的另一件事是 session 劫持。例如，如果有人在公共(public) wifi 上窃取了您的 cookie，他们可以将其呈现给服务器，服务器将表现得好像是您一样。这通常涉及网络流量嗅探。出于这些原因，最佳实践是对整个站点使用 SSL，并在 web.config/system.web/authorization/forms 中将 cookie 设置为仅 HTTP 和安全(仅通过 https 连接呈现)。 HTTP 仅意味着它对客户端 Javascript 不可用。 HTTP Only and Secure 实际上意味着仅 HTTPS。这仅在您在整个站点上使用 SSL 时才有效。
FormsAuthentication 可以在移动网络浏览器上正常工作。它只要求客户端接受 cookie。据我所知，所有移动设备都允许这样做。
关于asp.net-mvc - FormsAuthentication.SetAuthCookie 与 FormsAuthentication.Encrypt，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23301445/