Ich versuche, einige Begriffe und Mechanismen in den Griff zu bekommen und herauszufinden, wie sie sich zueinander verhalten oder wie sie sich überschneiden. Die Authentifizierung einer theoretischen Webanwendung und einer mobilen Anwendung steht im Mittelpunkt. **Der Fokus liegt auf dem genauen Unterschied zwischen Token-basierter Authentifizierung und Cookie-basierter Authentifizierung und ob/wie sie sich überschneiden.
http basic/digest und komplexe Systeme wie oauth/aws auth interessieren mich nicht
Ich habe ein paar Behauptungen, die ich gerne in die Welt setzen würde, um zu sehen, ob sie richtig sind.
Ich hoffe, dass ich nicht zu weit daneben liege und bin für jede Hilfe dankbar!
Bei der Sitzungsbasierten Authentifizierung übernimmt der Server die gesamte Arbeit auf der Server-Seite. Grob gesagt authentifiziert sich ein Client mit seinen Anmeldedaten und erhält eine "session_id" (die in einem Cookie gespeichert werden kann), die er an jede nachfolgende ausgehende Anfrage anhängt. Man könnte dies also als Token bezeichnen, da es einer Reihe von Anmeldeinformationen entspricht. Die Zeichenkette session_id
hat jedoch nichts Besonderes an sich. Es ist nur ein Bezeichner und der Server macht alles andere. Sie ist zustandsabhängig. Er assoziiert die Kennung mit einem Benutzerkonto (z.B. im Speicher oder in einer Datenbank). Er kann diese Sitzung auf bestimmte Operationen oder einen bestimmten Zeitraum beschränken und sie ungültig machen, wenn Sicherheitsbedenken bestehen. Noch wichtiger ist, dass es all dies im laufenden Betrieb tun und ändern kann. Außerdem kann es jede Bewegung des Benutzers auf der/den Website(s) protokollieren. Mögliche Nachteile sind die schlechte Skalierbarkeit (insbesondere bei mehr als einer Serverfarm) und der hohe Speicherbedarf.
Bei der Token-basierten Authentifizierung wird keine Sitzung serverseitig aufrechterhalten (zustandslos). Die ersten Schritte sind die gleichen. Die Anmeldeinformationen werden gegen ein Token ausgetauscht, das dann an jede nachfolgende Anfrage angehängt wird (es kann auch in einem Cookie gespeichert werden). Um jedoch den Speicherbedarf zu verringern, die Skalierbarkeit zu erleichtern und völlige Flexibilität zu gewährleisten (Token können mit einem anderen Client ausgetauscht werden), wird eine Zeichenfolge mit allen erforderlichen Informationen ausgegeben (das Token), die nach jeder Anfrage des Clients an den Server überprüft wird. Es gibt eine Reihe von Möglichkeiten, Token zu verwenden/erstellen:
Verwendung eines Hash-Mechanismus, z.B. HMAC-SHA1
Token = Benutzer_ID|Ablaufdatum|HMAC(Benutzer_ID|Ablaufdatum, k)
wobei user_id
und expiry_date
im Klartext gesendet werden und der resultierende Hash angehängt wird (k
ist nur dem Server bekannt).
Symmetrische Verschlüsselung des Tokens, z.B. mit AES
Token = AES(user_id|Verfallsdatum, x)
wobei x
den Ver-/Entschlüsselungsschlüssel darstellt.
Asymmetrisch verschlüsseln, z.B. mit RSA
Token = RSA(Benutzer_id|Ablaufdatum, privater Schlüssel)
Produktionssysteme sind in der Regel komplexer als diese beiden Archetypen. Amazon zum Beispiel verwendet beide Mechanismen auf seiner Website. Auch Hybride können verwendet werden, um Token wie unter 2 beschrieben auszugeben und auch eine Benutzersitzung damit zu verknüpfen, um den Benutzer zu verfolgen oder möglicherweise zu widerrufen und trotzdem die Client-Flexibilität klassischer Token beizubehalten. Auch OAuth 2.0 verwendet kurzlebige und spezifische Inhaber-Tokens und längerlebige Refresh-Tokens, um z. B. Inhaber-Tokens zu erhalten.
Quellen:
HTTP ist zustandslos, und um einen authentifizierten Zustand zu haben, benötigen Sie eine Art Token, das verwendet wird, um Informationen über den Benutzer zu referenzieren. Diese Sitzungs-ID hat normalerweise die Form eines zufälligen Tokens, das als Cookie-Wert gesendet wird. Ein OAuth Access Token wird verwendet, um einen Benutzer und den Umfang der Ressourcen zu identifizieren, auf die dieser Benutzer Zugriff hat. In Anwendungen, die OAuth Single-Sign-On verwenden, wird ein OAuth Access Token in der Regel gegen eine Session-ID ausgetauscht, die eine größere Anzahl von Benutzerzuständen verfolgen kann.
Aus der Sicht eines Angreifers ist die Entführung einer Sitzungs-ID oder eines OAuth Access Token so gut wie ein Benutzername und ein Passwort, und manchmal ist es sogar besser. 2tzungs-IDs müssen Sicherheitseigenschaften haben,2 die Benutzerkonten vor Kompromittierung schützen.
Aus der Sicht des Entwicklers gilt: Niemals das Rad neu erfinden. Verwenden Sie den von Ihrer Plattform bereitgestellten Sitzungsmanager und stellen Sie sicher, dass er gemäß den OWASP-Sitzungsmanagement-Richtlinien konfiguriert ist.
Also, auf der Session-basierte Authentifizierung, um die Sicherheit beim Zugriff auf Ressourcen, die man benötigt zu erhöhen: