FormsAuthentication.SetAuthCookie vs FormsAuthentication.Encrypt

Question

Frage # 1: Ist setAuthCookie weniger sicher als FormsAuthentication.Encrypt (ticketVariable)?

Ich meine, wenn jemand versucht, das Cookie von setAuthCookie erstellt zu ändern, indem Sie den Benutzernamen ändern, nehme ich an, dass werde die Authentifizierung bei nachfolgenden Aufrufen verletzen?

Frage # 2: für diejenigen, die iPhones und Tablets für den Zugriff auf die Website verwenden, nehme ich an, dass FormsAuthentication fehlschlägt? Angesichts der Tatsache, dass ich keine cookieless-Option verwenden möchte, gibt es einen anderen Ansatz, um die Website auf beiden Smartphones Web-Browser und Ummm nicht-Smartphone Webbrowser sicher zu machen?

prost

Answer 1

SetAuthCookie schafft im Grunde eine neue FormsAuthenticationTicket mit den Optionen angegebenen Benutzernamen & Persistenz, serialisiert es, FormsAuthentication.Encrypt() 's es und setzt es in der Response.Cookies Sammlung. SetAuthCookie und GetAuthCookie rufen beide FormsAuthentication.Encrypt indirekt auf.

Bei nachfolgenden Anfragen behandelt die FormsAuthentiationModule das AuthenticateRequest Ereignis. Wenn ein Cookie erkannt wird (der möglicherweise abgelaufen ist), wird versucht, den Wert mit dem Computerschlüssel zu entschlüsseln (möglicherweise manipuliert) und in ein FormsAuthenticationTicket zu deserialisieren (möglicherweise beschädigt). Wenn nichts von dem (schlechten Zeug) passiert, enthält das Ticket den Benutzernamen, das Ausstellungsdatum, die Ablaufinfo usw. Wenn das Ticket nicht abgelaufen ist, werden ein IIdentity und IPrincipal erstellt und HttpContext.Current.User und Thread zugewiesen. CurrentThread.Principal. In .NET 4.5 und später (denke ich) ist dies Claims-Based (ClaimsIdentity, ClaimsPrincipal). Zuvor war es ein (GenericPrincipal, FormsIdentity), denke ich.

überhaupt auf der Benutzerseite Manipulation bewirkt, dass die Anfrage als anonym behandelt werden. Es kann nicht entschlüsselt werden. Die einzigen Dinge, die diese Validierung beeinträchtigen würden, wären, wenn der computerKey in web.config/machine.config irgendwie in die Hände eines Angreifers geraten wäre oder wenn ein Fehler im Framework-Code vorgelegen hätte (suchen Sie für ein historisches Beispiel nach Padding Oracle)).

Abgesehen davon, die andere Sache, auf die man achten sollte, wäre Session-Hijacking. Wenn jemand Ihr Cookie zum Beispiel auf einem öffentlichen WLAN-Gerät stiehlt, kann es es dem Server präsentieren und der Server verhält sich so, als ob Sie es wären. Dies beinhaltet im Allgemeinen Netzwerkverkehr-Sniffing. Aus diesen Gründen empfiehlt es sich, SSL für Ihre gesamte Website zu verwenden und den Cookie in web.config/system.web/authorisation/forms nur auf HTTP und Secure (nur über https-Verbindungen bereitgestellt) zu setzen. HTTP bedeutet nur, dass es für clientseitiges JavaScript nicht verfügbar ist. Nur HTTP und Sicher bedeutet nur HTTPS. Dies funktioniert nur, wenn Sie SSL auf Ihrer gesamten Website verwenden.

FormsAuthentication funktioniert problemlos in mobilen Webbrowsern. Es erfordert lediglich, dass der Client Cookies akzeptiert. Soweit ich weiß, erlauben dies alle mobilen Geräte.