it-swarm.com.de

Was ist, wenn JWT gestohlen wird?

Ich versuche, eine zustandslose Authentifizierung mit JWT für meine RESTful-APIs zu implementieren.

AFAIK, JWT ist im Grunde eine verschlüsselte Zeichenfolge, die während eines REST - Aufrufs als HTTP-Header übergeben wird.

Aber was ist, wenn ein Lauscher die Anfrage sieht und das Token stiehlt? Dann wird er in der Lage sein, Anfrage mit meiner Identität zu fälschen?

Tatsächlich gilt dieses Problem für alle tokenbasierte Authentifizierung.

Wie kann man das verhindern? Ein sicherer Kanal wie HTTPS?

157
smwikipedia

Ich bin der Autor einer Knotenbibliothek, die sich eingehend mit der Authentifizierung befasst, express-stormpath , daher werde ich hier einige Informationen einfügen.

Zunächst werden JWTs in der Regel [~ # ~] nicht [~ # ~] verschlüsselt. Während es eine Möglichkeit gibt, JWTs zu verschlüsseln (siehe: JWEs ), ist dies in der Praxis aus vielen Gründen nicht sehr verbreitet.

Als nächstes ist jede Form der Authentifizierung (unter Verwendung von JWTs oder nicht) MitM-Angriffen (Man-in-the-Middle) ausgesetzt. Diese Angriffe treten auf, wenn ein Angreifer Ihren Netzwerkverkehr anzeigen kann, während Sie Anfragen über das Internet stellen. Dies ist, was Ihr ISP sehen kann, die NSA, etc.

Dies verhindert SSL: Durch die Verschlüsselung Ihres NETZWERK-Verkehrs von Ihrem Computer -> auf einigen Servern kann ein Dritter, der Ihren Netzwerkverkehr überwacht, Ihre Token, Kennwörter oder Ähnliches NICHT sehen, es sei denn, er ist irgendwie dazu in der Lage um eine Kopie des privaten SSL-Schlüssels des Servers zu erhalten (unwahrscheinlich). Aus diesem Grund ist SSL für alle Arten der Authentifizierung obligatorisch.

Angenommen, jemand kann Ihr SSL ausnutzen und Ihr Token anzeigen: Die Antwort auf Ihre Frage lautet: [~ # ~] yes [~ # ~] kann der Angreifer dieses Token verwenden, um sich als Sie auszugeben und Anfragen an Ihren Server zu richten.

Hier kommen die Protokolle ins Spiel.

JWTs sind nur ein Standard für ein Authentifizierungstoken. Sie können für so ziemlich alles verwendet werden. Der Grund, warum JWTs so cool sind, ist, dass Sie zusätzliche Informationen in sie einbetten können und überprüfen können, dass niemand damit in Konflikt geraten ist (Signieren).

JWTs selbst haben jedoch nichts mit "Sicherheit" zu tun. In jeder Hinsicht sind JWTs mehr oder weniger dasselbe wie API-Schlüssel: nur zufällige Zeichenfolgen, mit denen Sie sich irgendwo bei einem Server authentifizieren.

Was Ihre Frage interessanter macht, ist das verwendete Protokoll (höchstwahrscheinlich OAuth2).

OAuth2 wurde entwickelt, um Clients TEMPORARY-Token (wie JWTs!) Für die Authentifizierung nur für einen KURZEN ZEITRAUM zur Verfügung zu stellen.

Die Idee ist, dass der Angreifer Ihr gestohlenes Token nur für kurze Zeit verwenden kann.

Bei OAuth2 müssen Sie sich von Zeit zu Zeit erneut beim Server authentifizieren, indem Sie Ihren Benutzernamen/Ihr Kennwort OR API-Anmeldeinformationen angeben und anschließend ein Token zurückerhalten.

Da dieser Vorgang von Zeit zu Zeit stattfindet, ändern sich Ihre Token häufig, wodurch es für Angreifer schwieriger wird, sich ständig als Sie auszugeben, ohne große Probleme zu haben.

Hoffentlich hilft das ^^

243
rdegges

Ich weiß, dass dies eine alte Frage ist, aber ich denke, ich kann meine 0,50 USD hier fallen lassen, wahrscheinlich kann jemand meine Herangehensweise verbessern oder ein Argument liefern, um sie völlig abzulehnen. Ich verwende JWTs in einer RESTful-API über HTTPS (ofc).

Damit dies funktioniert, sollten Sie immer kurzlebige Token ausgeben (abhängig von den meisten Fällen setze ich in meiner App den Anspruch exp auf 30 Minuten und ttl auf 3 Tage. Sie können dieses Token aktualisieren, solange sein ttl noch gültig ist und das Token nicht auf die schwarze Liste gesetzt wurde

Für den authentication service, Um Token ungültig zu machen, verwende ich gerne eine speicherinterne Cache-Ebene ( redis in meinem Fall) als ein JWT blacklist/ban-list vor, abhängig von einigen Kriterien: (Ich weiß, dass es die RESTful-Philosophie verletzt, aber die gespeicherten Dokumente sind wirklich kurzlebig, da ich ihre verbleibende Zeit auf die schwarze Liste setze -live -ttl claim-)

Hinweis: Tokens auf der schwarzen Liste können nicht automatisch aktualisiert werden

  • Wenn user.password Oder user.email Aktualisiert wurden (Kennwortbestätigung erforderlich), gibt der Authentifizierungsdienst ein aktualisiertes Token zurück und macht die vorherigen Token ungültig (Sperrliste) irgendwie kompromittiert, können Sie diesen Benutzer bitten, sein Passwort zu ändern. Wenn Sie die Blacklist nicht dafür verwenden möchten, können Sie das (am) geltend gemachte) iat -Anspruch gegen das user.updated_at - Feld validieren (wenn jwt.iat < user.updated_at Dann ist JWT nicht gültig).
  • Benutzer absichtlich abgemeldet.

Schließlich validieren Sie das Token wie jeder andere auch.

Anmerkung 2: Anstatt das Token selbst (das wirklich lang ist) als Cache-Schlüssel zu verwenden, empfehle ich, ein UUID-Token für den Anspruch jti zu generieren und zu verwenden. Was gut ist und ich denke (nicht sicher, da es mir gerade eingefallen ist), können Sie dieselbe UUID wie das CSRF-Token verwenden, indem Sie ein secure/non-http-only Cookie damit zurückgeben und korrektes Implementieren des X-XSRF-TOKEN - Headers mit js. Auf diese Weise vermeiden Sie den Rechenaufwand für die Erstellung eines weiteren Tokens für CSRF-Prüfungen.

26
Frondor

Es tut mir leid, dass ich ein bisschen zu spät dran bin, aber ich hatte ähnliche Bedenken und möchte jetzt etwas dazu beitragen.

1) rdegges fügte einen hervorragenden Punkt hinzu, dass JWT nichts mit der "Sicherheit" zu tun hat und einfach überprüft, ob jemand die Nutzlast durcheinander gebracht hat oder nicht (Signieren); SSL hilft gegen Verstöße zu verhindern.

2) Wenn nun auch ssl in irgendeiner Weise gefährdet ist, kann jeder Lauscher unseren Inhaber-Token (JWT) stehlen und sich als echter Benutzer ausgeben. Als nächster Schritt kann der "Beweis gesucht werden Besitz " von JWT vom Auftraggeber.

3) Bei diesem Ansatz verfügt der Moderator des JWT nun über einen bestimmten POP-Schlüssel (Proof-Of-Possession), mit dem der Empfänger kryptografisch bestätigen kann, ob die Anforderung von derselben stammt authentischer Benutzer oder nicht.

Ich habe Proof of Possesion hierauf verwiesen und bin vom Ansatz überzeugt.

Ich werde mich freuen, wenn ich etwas beitragen kann.

Prost (y)

4
yanky_cranky