it-swarm.com.de

Entmystifizierung der Webauthentifizierung (zustandslose Sitzungscookies)

Ich recherchiere derzeit nach Benutzerauthentifizierungsprotokollen für eine Website, die ich entwickle. Ich möchte ein Authentifizierungscookie erstellen, damit Benutzer zwischen den Seiten angemeldet bleiben können.

Hier ist meine erste Bash:

cookie = user_id|expiry_date|HMAC(user_id|expiry_date, k)

Wobei kHMAC(user_id|expiry_date, sk) und sk ein 256-Bit-Schlüssel ist, der nur dem Server bekannt ist. HMAC ist ein SHA-256-Hash. Beachten Sie, dass '|' ist ein Trennzeichen, nicht nur eine Verkettung.

Dies sieht in PHP (Hinweis, diese Frage ist sprachunabhängig, PHP ist nur ein Beispiel)) folgendermaßen aus:

$key = hash_hmac('sha256', $user_id . '|' . $expiry_time, SECRET_KEY);
$digest = hash_hmac('sha256', $user_id . '|' . $expiry_time, $key);
$cookie = $user_id . '|' . $expiry_time . '|' . $digest;

Ich kann sehen, dass es anfällig für Wiederholungsangriffe ist, wie in Ein sicheres Cookie-Protokoll angegeben, aber gegen Volumenangriffe und kryptografisches Spleißen resistent sein sollte.

DIE FRAGE: Bin ich hier auf dem richtigen Weg oder gibt es eine massive Sicherheitslücke, die ich übersehen habe? Gibt es eine Möglichkeit, sich gegen Wiederholungsangriffe zu verteidigen, die mit dynamisch zugewiesenen IP-Adressen funktioniert und keine Sitzungen verwendet? Ich möchte nichts auf der Serverseite speichern, damit dies funktioniert.

Außerdem plane oder rolle ich nicht meine eigenen. Ich bitte dies, um besser beurteilen zu können, welche Lösung ich wählen soll. Also keine "Just use X-Lösung" -Antworten ohne irgendeine Erklärung.

ANMERKUNGEN

Das neueste Material, das ich gelesen habe:
Vor- und Nachteile der Clientauthentifizierung im Web aka Fu et al.
( https://pdos.csail.mit.edu/papers/webauth:sec10.pdf )

Ein sicheres Cookie-Protokoll alias Liu et al.
( http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf )
, das die vorherige Methode erweitert

Gehärtete zustandslose Sitzungscookies
( http://www.lightbluetouchpaper.org/2008/05/16/hardened-stateless-session-cookies/ )
, was auch die vorherige Methode erweitert.

Da das Thema äußerst kompliziert ist, suche ich nur nach Antworten von Sicherheitsexperten mit realer Erfahrung in der Erstellung und Aufhebung von Authentifizierungsschemata.

42
Joony

"Wiederholungsangriffe" gelten nicht wirklich für Cookies, da ein Cookie per Definition ist, was wiedergegeben werden soll: Der Browser des Benutzers sendet denselben Cookie-Wert zurück, und so ist Ihr Cookie Server weiß, dass es der gleiche Benutzer ist.

Was Sie vermeiden möchten, ist, dass jemand die Leitung ausspioniert, den Cookie-Wert beobachtet und dann denselben Cookie über seine eigenen Verbindungen sendet. Die einzige bekannte praktische Lösung besteht darin, das gesamte Protokoll in einem Tunnel auszuführen, der die Vertraulichkeit und Integrität der Daten während der Übertragung gewährleistet. Dies wird als "SSL" (auch bekannt als [~ # ~] https [~ # ~]) bezeichnet. ).

Dann gibt es zwei Möglichkeiten, die Cookie-Werte auf dem Server zu generieren und zu überprüfen:

  • Sie können einfach einen zufälligen Wert von ausreichender Größe (d. H. 16 Byte oder so) generieren, so dass es für einen Angreifer höchst unwahrscheinlich ist, den Wert aus purem Glück zu erraten. Der Server merkt sich für jeden Benutzer sein aktuelles "Sitzungstoken" als zusätzliche Spalte in der Datenbank "Benutzer".

  • Sie erzeugen das Token als einen nicht fälschbaren Wert, der deterministisch aus der Benutzerkennung berechnet wird. Das ist was Sie tun, und das ist ein vernünftiges Konzept. Anstatt einen zusätzlichen Status auf dem Server zu speichern, verlagern Sie ihn grundsätzlich auf den Client und verwenden einen MAC mit einem serverseitigen Schlüssel, damit Clients "gültige" Cookie-Werte können nicht gefälscht werden.

Ihr Code beschreibt zwei verschachtelte HMAC-Aufrufe, was seltsam und ungerechtfertigt ist. Ein Anruf ist ausreichend. Die generische Konstruktion besteht darin, dass ein Cookie einen Wert v und einen MAC m enthält, sodass v den gewünschten Status codiert im Client zu speichern, und m wird über v berechnet. Der Status, den Sie in Ihrem Fall speichern möchten, lautet: "Dieser Client hat die Benutzer-ID i und ist zum Zeitpunkt t angemeldet." Sie können jede gewünschte Codierung verwenden, vorausgesetzt, Sie können sie eindeutig decodieren.

Um es zusammenzufassen: Das Erstellen von Cookie-Werten mit einem MAC ist eine gültige Methode zur Sitzungsverwaltung, und HMAC/SHA-256 ist dafür gut geeignet. Sie müssen es sich jedoch als Optimierung vorstellen: Sie speichern Werte im Client, um zu vermeiden, dass sie auf dem Server gespeichert werden. Dies hat die unglückliche Folge, dass der Client Daten vergessen kann, die außerhalb Ihrer Kontrolle liegen (der Client kann das Cookie zerstören) oder Zeitverzerrungen ausführen kann (der Client kann den in seinem Browser gespeicherten Wert in einen älteren Cookie-Wert ändern - ein Problem, das auftritt gemildert durch Aufnahme von Daten in die Cookies (unter Kontrolle des MAC).

Wenn Sie die Statusserverseite beibehalten und nur zufällige Cookie-Werte verwenden können, tun Sie dies: Es ist einfacher und gibt dem Server mehr Kontrolle.

35
Thomas Pornin

Der erste Schritt zum Sichern einer Webanwendung ist die Verwendung von SSL. Das hält Ihr Cookie vertraulich, verhindert Wiederholungsangriffe, stellt sicher, dass der Benutzer mit dem richtigen Server spricht, verhindert MitM, verhindert, dass Angreifer die Daten im Netzwerk ändern ...

Setzen Sie dann das Flag secure für das Cookie, damit es nur über SSL gesendet wird. Das Setzen des Flags http-only, Um zu verhindern, dass Javascript gelesen wird, tut auch nicht weh.

Zum Schluss noch zu Ihrem Cookie-Schema:

  • Der verschachtelte HMAC bringt Ihnen nichts. Gehen Sie einfach mit user_id|expiry_date|HMAC(user_id|expiry_date, SECRET_KEY)
  • Ändern Sie SECRET_KEY Regelmäßig
  • Der user_id Darf sich niemals ändern. Verwenden Sie die numerische Benutzer-ID, nicht den Benutzernamen oder die E-Mail-Adresse
  • Weder user_id Noch expiry_date Sollten jemals einen | Enthalten, um eine saubere Domänentrennung zu gewährleisten
  • Wenn Sie paranoid sind, verwenden Sie einen speziellen Anmeldeserver, der das Cookie signiert, anstatt es zu MACen. Der Anmeldeserver ist also der einzige Server, der über den zum Erstellen von Cookies erforderlichen Schlüssel verfügt. Normale Webserver können ihn nur validieren. => reduziert die Angriffsfläche
  • Der Server kann für jeden Benutzer gültige Cookies erstellen. Das könnte unerwünscht sein.
13
CodesInChaos

Zuallererst:

Erfinden Sie keine eigenen Sicherheitsprotokolle. Es ist sehr wahrscheinlich, dass Sie etwas falsch machen.

Nun, das ist aus dem Weg, schauen wir uns das an. Wenn ich jemals HMAC(userid|expiry_date, k) erhalten kann, ohne mich anzumelden oder mich als dieser Benutzer authentifiziert zu haben, habe ich die Sicherheit dieses Systems verletzt. Dies erstreckt sich auf alle Arten von Problemen, wie z. B. Angriffe auf Sitzungsfixierung oder Sitzungsentführung (häufig verursacht durch nicht oder falsches Verwenden von SSL/TLS).

Wenn Sie das Sitzungscookie überprüfen, verlieren Sie Informationen aus den Timing-Seitenkanälen? Verwenden Sie HMAC definitiv richtig? Sie sagten, Ihr HMAC ist SHA-256, meinen Sie eigentlich HMAC-SHA-256? Warum eine komplizierte HMAC-Prozedur durchlaufen, wenn Sie einfach eine zufällige Zeichenfolge generieren und sie einem Benutzer auf dem Server zuordnen könnten (z. B. in einer Datenbank)? Warum nicht einfach user_id|expiry_date|HMAC-SHA-256(user_id|expiry_date, sk) verwenden (wobei | Verkettung ist, nicht das Literal-Pipe-Zeichen)?

Informationen zum Schutz vor Wiederholungsangriffen in einer webbasierten Umgebung finden Sie unter CSRFGuard-Projekt von OWASP . Sie werden es nicht direkt integrieren können, aber es kann irgendwo ein PHP Äquivalent) geben. Es ist alles umstritten, wenn Ihre Site für XSS-Angriffe anfällig ist.

Sicherheit sollte an ein angesehenes, kampferprobtes Framework übergeben werden, nicht ad hoc

Bearbeiten, ein kurzes Wort zu Sitzungsfixierungsangriffen:

Ich ging davon aus, dass Sie wahrscheinlich Verwundbar sind, wenn Sie die Sicherheit nicht an ein gut getestetes Framework übergeben. Sie müssen grundsätzlich überprüfen, ob Sie einen bestimmten Sitzungsschlüssel ausgeben, wenn sich der Benutzer authentifiziert (d. H. Anders als der, mit dem der Benutzer begonnen hat). Mit der obigen Strategie würde sich user_id|expiry_date|HMAC(user_id|expiry_date, k) nicht ändern, wenn sich der Benutzer authentifiziert, wodurch er für einen Sitzungsfixierungsangriff anfällig wird.

8
Tinned_Tuna

Da das Thema äußerst kompliziert ist, suche ich nur nach Antworten von Sicherheitsexperten mit realer Erfahrung in der Erstellung und Aufhebung von Authentifizierungsschemata.

Sie haben Recht, dass das Thema äußerst kompliziert ist.

Gehen Sie mit den von Ihrem Framework bereitgestellten Sitzungsfunktionen und versuchen Sie nicht, Ihre eigenen zu rollen. Wenn Sie plain PHP anstelle eines Frameworks ... shudders verwenden.

3
user10211