Wenn Sie JWT entschlüsseln können, wie sicher sind sie dann?

Question

Wenn ich ein JWT bekomme und ich das Nutzdaten entschlüsseln kann, wie ist das dann sicher? Könnte ich nicht einfach das Token aus dem Header herausgreifen, entschlüsseln, die Benutzerinformationen im Nutzdaten ändern und es dann mit dem gleichen korrekt verschlüsselten Geheimnis zurücksenden?

Ich weiß, sie müssen sicher sein, aber ich würde wirklich gerne die Technologien verstehen. Was fehlt mir?

Answer 1

JWTs können entweder signiert, verschlüsselt oder beides sein. Wenn ein Token signiert ist, aber nicht verschlüsselt, kann jeder den Inhalt lesen, aber wenn man den privaten Schlüssel nicht kennt, kann man ihn nicht ändern. Andernfalls wird der Empfänger feststellen, dass die Signatur nicht mehr übereinstimmt.

Antwort auf deinen Kommentar: Ich bin mir nicht sicher, ob ich deinen Kommentar richtig verstehe. Nur um sicher zu gehen: Kennen und verstehen Sie digitale Signaturen? Ich werde einfach kurz eine Variante erklären (HMAC, die symmetrisch ist, aber es gibt viele andere).

Angenommen, Alice möchte Bob eine JWT senden. Sie kennen beide ein gemeinsames Geheimnis. Mallory kennt dieses Geheimnis nicht, möchte aber eingreifen und die JWT ändern. Um das zu verhindern, berechnet Alice Hash(payload + secret) und hängt dies als Signatur an.

Beim Empfang der Nachricht kann Bob auch Hash(payload + secret) berechnen, um zu überprüfen, ob die Signatur übereinstimmt. Wenn jedoch Mallory etwas im Inhalt ändert, ist sie nicht in der Lage, die entsprechende Signatur zu berechnen (die Hash(newContent + secret) wäre). Sie kennt das Geheimnis nicht und hat keine Möglichkeit, es herauszufinden. Das bedeutet, wenn sie etwas ändert, passt die Signatur nicht mehr und Bob wird die JWT einfach nicht akzeptieren.

Angenommen, ich sende einer anderen Person die Nachricht {"id":1} und signiere sie mit Hash(content + secret). (+ steht hier einfach für Verkettung). Ich verwende die SHA256-Hashfunktion, und die Signatur, die ich erhalte, ist: 330e7b0775561c6e95797d4dd306a150046e239986f0a1373230fda0235bda8c. Jetzt bist du dran: Nimm die Rolle von Mallory ein und versuche, die Nachricht {"id":2} zu signieren. Du kannst es nicht, weil du nicht weißt, welches Geheimnis ich verwendet habe. Wenn ich davon ausgehe, dass der Empfänger das Geheimnis kennt, KANN er die Signatur jeder Nachricht berechnen und überprüfen, ob sie korrekt ist.

Answer 2

Lass uns vom Anfang an diskutieren:

JWT ist ein sehr moderner, einfacher und sicherer Ansatz, der für Json Web Tokens steht. Json Web Tokens sind eine zustandslose Lösung für die Authentifizierung. Es ist also nicht erforderlich, irgendeinen Sitzungszustand auf dem Server zu speichern, was natürlich perfekt für restful APIs ist. Restful APIs sollten immer zustandslos sein, und das am weitesten verbreitete Alternativ zur Authentifizierung mit JWTs ist es, einfach den Login-Zustand des Benutzers auf dem Server mithilfe von Sitzungen zu speichern. Aber das folgt natürlich nicht dem Prinzip, dass restful APIs zustandslos sein sollten, und deshalb sind Lösungen wie JWT beliebt und effektiv geworden.

Lassen Sie uns nun herausfinden, wie die Authentifizierung tatsächlich mit Json Web Tokens funktioniert. Angenommen, wir haben bereits einen registrierten Benutzer in unserer Datenbank. Der Client des Benutzers beginnt, indem er einen POST-Antrag mit dem Benutzernamen und dem Passwort stellt. Die Anwendung überprüft dann, ob der Benutzer vorhanden ist und ob das Passwort korrekt ist, dann generiert die Anwendung einen eindeutigen Json Web Token nur für diesen Benutzer.

Der Token wird mithilfe eines geheimen Strings erstellt, der auf einem Server gespeichert ist. Als Nächstes sendet der Server diesen JWT an den Client, der ihn entweder in einem Cookie oder im lokalen Speicher speichert.

Auf diese Weise ist der Benutzer authentifiziert und im Grunde genommen in unsere Anwendung eingeloggt, ohne einen Zustand auf dem Server zu hinterlassen.

Der Server weiß also tatsächlich nicht, welcher Benutzer eingeloggt ist, aber natürlich weiß der Benutzer, dass er eingeloggt ist, weil er einen gültigen Json Web Token hat, der ein bisschen wie ein Reisepass ist, um auf geschützte Teile der Anwendung zuzugreifen.

Noch einmal, um sicherzugehen, dass Sie das Konzept verstanden haben. Ein Benutzer ist eingeloggt, sobald er seinen eindeutigen gültigen Json Web Token zurückbekommt, der nirgendwo auf dem Server gespeichert ist. Und deshalb ist dieser Prozess vollständig zustandslos.

Dann, jedes Mal wenn ein Benutzer auf eine geschützte Route zugreifen möchte, beispielsweise auf seine Benutzerprofil-Daten. Sendet er seinen Json Web Token zusammen mit einer Anfrage, es ist ein bisschen wie seinen Reisepass vorzuzeigen, um Zugang zu dieser Route zu erhalten.

Sobald die Anfrage den Server erreicht, wird unsere App dann überprüfen, ob der Json Web Token tatsächlich gültig ist und ob der Benutzer wirklich derjenige ist, für den er sich ausgibt. Nun werden die angeforderten Daten an den Client gesendet und wenn nicht, wird es einen Fehler geben, der dem Benutzer mitteilt, dass er nicht berechtigt ist, auf diese Ressource zuzugreifen.

All diese Kommunikation muss über https erfolgen, also über sicheres verschlüsseltes Http, um zu verhindern, dass jemand Zugriff auf Passwörter oder Json Web Tokens erhält. Nur dann haben wir ein wirklich sicheres System.

Ein Json Web Token sieht so aus wie der linke Teil dieses Screenshots, der aus dem JWT-Debugger auf jwt.io stammt. Im Wesentlichen, es ist ein Codierungsstring, der aus drei Teilen besteht. Der Header, die Nutzlast und die Signatur. Jetzt ist der Header einfach Metadaten über das Token selbst und die Nutzlast sind die Daten, die wir in das Token kodieren können, beliebige Daten, die wir möchten. Je mehr Daten wir hier kodieren wollen, desto größer wird das JWT. Wie auch immer, diese beiden Teile sind einfach Klartext, der kodiert, aber nicht verschlüsselt wird.

Daher kann jeder sie dekodieren und lesen, wir können hier keine sensiblen Daten speichern. Aber das ist überhaupt kein Problem, weil im dritten Teil, also in der Signatur, wird es wirklich interessant. Die Signatur wird mithilfe des Headers, der Nutzlast und des Geheimnisses erstellt, das auf dem Server gespeichert ist.

Und dieser gesamte Prozess wird dann signing the Json Web Token genannt. Der Signaturalgorithmus verwendet den Header, die Nutzlast und das Geheimnis, um eine eindeutige Signatur zu erstellen. Also nur diese Daten plus das Geheimnis können diese Signatur erstellen, verstanden? Dann, zusammen mit dem Header und der Nutzlast, bilden diese Signatur das JWT, das dann an den Client gesendet wird.

Wenn der Server ein JWT erhält, um Zugriff auf eine geschützte Route zu gewähren, muss er es überprüfen, um festzustellen, ob der Benutzer wirklich derjenige ist, für den er sich ausgibt. Mit anderen Worten, es wird überprüft, ob niemand die Daten im Header und in der Nutzlast des Tokens geändert hat. Also, dieser Verifizierungsschritt überprüft, ob keine dritte Partei tatsächlich entweder den Header oder die Nutzlast des Json Web Tokens geändert hat.

Also, wie funktioniert diese Verifizierung tatsächlich? Nun, es ist eigentlich ziemlich einfach. Sobald das JWT empfangen wurde, wird die Verifizierung den Header und die Nutzlast nehmen und zusammen mit dem immer noch auf dem Server gespeicherten Geheimnis im Grunde einen Test-Signatur erstellen.

Aber die ursprüngliche Signatur, die generiert wurde, als das JWT zum ersten Mal erstellt wurde, ist immer noch im Token enthalten, richtig? Und das ist der Schlüssel zu dieser Verifizierung. Denn jetzt müssen wir nur noch die Test-Signatur mit der ursprünglichen Signatur vergleichen. Und wenn die Test-Signatur mit der ursprünglichen Signatur übereinstimmt, dann bedeutet das, dass die Nutzlast und der Header nicht geändert wurden.

Denn wenn sie geändert worden wären, dann müsste die Test-Signatur anders sein. Daher, in dem Fall, dass keine Daten verändert wurden, können wir dann den Benutzer authentifizieren. Und natürlich, wenn die beiden Signaturen tatsächlich unterschiedlich sind, nun, dann bedeutet das, dass jemand die Daten manipuliert hat. Normalerweise indem sie versuchen, die Nutzlast zu ändern. Aber diese dritte Partei, die die Nutzlast manipuliert, hat natürlich keinen Zugriff auf das Geheimnis, also können sie das JWT nicht signieren. Deshalb wird die ursprüngliche Signatur niemals mit den manipulierten Daten übereinstimmen. Und deshalb wird die Verifizierung in diesem Fall immer scheitern. Und das ist der Schlüssel, der das gesamte System funktionieren lässt. Das ist die Magie, die JWT so einfach, aber auch extrem leistungsstark macht.

Answer 3

Sie können zu jwt.io gehen, Ihren Token einfügen und die Inhalte lesen. Das ist anfangs für viele Menschen irritierend.

Die kurze Antwort ist, dass JWT sich nicht mit Verschlüsselung befasst. Es kümmert sich um Validierung. Das heißt, es kann immer die Frage beantworten "Wurden die Inhalte dieses Tokens manipuliert"? Das bedeutet, dass die Manipulation des JWT-Tokens durch Benutzer sinnlos ist, weil der Server den Token erkennen und ignorieren wird. Der Server fügt beim Ausstellen eines Tokens an den Client eine Signatur basierend auf dem Payload hinzu. Später überprüft er den Payload und die übereinstimmende Signatur.

Die logische Frage ist, was ist der Grund, sich nicht um verschlüsselte Inhalte zu kümmern?

1. Der einfachste Grund ist, dass es davon ausgeht, dass dies größtenteils ein gelöstes Problem ist. Wenn Sie beispielsweise mit einem Client wie dem Webbrowser arbeiten, können Sie die JWT-Tokens in einem Cookie speichern, das secure (wird nicht über HTTP, sondern nur über HTTPS übertragen) ist und httpOnly (kann nicht von Javascript gelesen werden) und mit dem Server über einen verschlüsselten Kanal (HTTPS) kommuniziert. Sobald Sie wissen, dass Sie einen sicheren Kanal zwischen Server und Client haben, können Sie sicher JWT oder was auch immer Sie möchten austauschen.

2. Dies hält die Dinge einfach. Eine einfache Implementierung erleichtert die Übernahme, ermöglicht aber auch jedem Layer, das zu tun, was es am besten kann (lassen Sie HTTPS die Verschlüsselung übernehmen).

3. JWT ist nicht dafür gedacht, sensible Daten zu speichern. Sobald der Server den JWT-Token empfängt und validiert, ist er frei, die Benutzer-ID in seiner eigenen Datenbank nach zusätzlichen Informationen für diesen Benutzer zu suchen (wie Berechtigungen, Postanschrift usw.). Dies hält JWT klein und vermeidet unbeabsichtigte Informationslecks, weil jeder weiß, dass keine sensiblen Daten in JWT aufbewahrt werden sollen.

Es ist nicht viel anders als die Funktionsweise von Cookies selbst. Cookies enthalten oft unverschlüsselte Nutzlasten. Wenn Sie HTTPS verwenden, ist alles gut. Wenn nicht, empfiehlt es sich, sensible Cookies selbst zu verschlüsseln. Wenn dies nicht erfolgt, besteht die Möglichkeit eines "Man-in-the-Middle"-Angriffs. Ein Proxy-Server oder ISP liest die Cookies und spielt sie später wieder, als wären Sie es. Aus ähnlichen Gründen sollten JWT immer über eine sichere Schicht wie HTTPS ausgetauscht werden.

Answer 4

Der Inhalt eines JSON-Webtokens (JWT) ist nicht inhärent sicher, aber es gibt eine integrierte Funktion zur Überprüfung der Authentizität des Tokens. Ein JWT besteht aus drei Base64-codierten Zeichenfolgen, die durch Punkte getrennt sind. Die dritte ist die Signatur. In einem Public-Private-Key-System signiert der Aussteller die Token-Signatur mit einem privaten Schlüssel, der nur durch seinen entsprechenden öffentlichen Schlüssel überprüft werden kann.

Es ist wichtig, den Unterschied zwischen Aussteller und Überprüfer zu verstehen. Der Empfänger des Tokens ist für die Überprüfung verantwortlich.

Es gibt zwei entscheidende Schritte zur sicheren Verwendung von JWT in einer Webanwendung: 1) Senden sie über ein verschlüsseltes Medium und 2) Überprüfen der Signatur sofort nach Erhalt. Die asymmetrische Natur der Public-Key-Kryptographie macht die Überprüfung der JWT-Signatur möglich. Ein öffentlicher Schlüssel bestätigt, dass ein JWT von seinem entsprechenden privaten Schlüssel signiert wurde. Keine andere Kombination von Schlüsseln kann diese Überprüfung durchführen und somit Versuche der Identitätswechsel verhindern. Befolgen Sie diese beiden Schritte und wir können mathematisch sicherstellen, dass ein JWT authentisch ist.

Mehr lesen: Wie verifiziert ein öffentlicher Schlüssel eine Signatur?

Answer 5

Ich würde das mit einem Beispiel erklären.

Angenommen, ich habe mir $10 von Ihnen geliehen, dann habe ich Ihnen einen IOU mit meiner Unterschrift darauf gegeben. Ich werde Ihnen das Geld zurückerstatten, wann immer Sie oder jemand anderes mir diesen IOU vorlegen. Ich werde die Unterschrift überprüfen, um sicherzustellen, dass sie von mir stammt.

Ich kann nicht sicherstellen, dass Sie den Inhalt dieses IOU niemandem zeigen oder es sogar an eine dritte Person weitergeben. Mir ist nur wichtig, dass dieser IOU von mir unterschrieben ist, wenn jemand diesen IOU vorzeigt und mich bittet, ihn zu zahlen.

Die Funktionsweise von JWT ist ziemlich ähnlich, der Server kann nur sicherstellen, dass das empfangene Token von ihm selbst ausgestellt wurde.

Sie benötigen andere Maßnahmen, um es sicher zu machen, wie z.B. die Verschlüsselung bei der Übertragung mit HTTPS, die Sicherung des lokalen Speichers, in dem das Token gespeichert ist, und das Einrichten von Ursprüngen.