it-swarm.com.de

Wenn Sie JWT dekodieren können, wie sind sie sicher?

Ich liebe JWT. Es macht wirklich Spaß, damit zu arbeiten. Meine Frage lautet: Wenn ich ein JWT bekomme und die Nutzlast entschlüsseln kann, wie ist das sicher? Könnte ich nicht einfach das Token aus dem Header holen, die Benutzerinformationen in der Nutzlast dekodieren und ändern und sie mit demselben korrekt kodierten Geheimnis zurücksenden?

Ich weiß, dass sie sicher sein müssen, aber ich möchte die Technologien wirklich verstehen. Was vermisse ich? Vielen Dank!

227
PixMach

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

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

Nehmen wir an, Alice möchte einen Zeugen Jehovas an Bob senden. Beide kennen ein gemeinsames Geheimnis. Mallory kennt dieses Geheimnis nicht, will sich aber einmischen und den Zeugen Jehovas verändern. Um dies 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 Mallory jedoch etwas am Inhalt ändert, kann sie die passende Signatur nicht berechnen (das wäre Hash(newContent + secret)). Sie kennt das Geheimnis nicht und hat keine Möglichkeit, es herauszufinden. Das bedeutet, wenn sie etwas ändert, stimmt die Signatur nicht mehr überein und Bob akzeptiert das JWT einfach nicht mehr.

Nehmen wir an, ich sende einer anderen Person die Nachricht {"id":1} Und signiere sie mit Hash(content + secret). (+ ist hier nur Verkettung). Ich verwende die SHA256-Hash-Funktion und erhalte folgende Signatur: 330e7b0775561c6e95797d4dd306a150046e239986f0a1373230fda0235bda8c. Jetzt sind Sie dran: Spielen Sie die Rolle von Mallory und versuchen Sie, die Nachricht zu unterschreiben {"id":2}. Das kannst du nicht, weil du nicht weißt, welches Geheimnis ich benutzt habe. Wenn ich annehme, dass der Empfänger das Geheimnis kennt, KANN er die Signatur einer Nachricht berechnen und prüfen, ob sie korrekt ist.

299
Misch

Sie können gehen zu jwt.io , füge dein Token ein und lies den Inhalt. Dies ist für eine Menge Leute anfangs ein Jarring.

Die kurze Antwort lautet, dass sich JWT nicht mit Verschlüsselung befasst. Es kümmert sich um die Validierung. Das heißt, es kann immer die Antwort für "Haben Sie den Inhalt dieses Tokens manipuliert" erhalten? Dies bedeutet, dass die Manipulation des JWT-Tokens durch den Benutzer zwecklos ist, da der Server das Token kennt und ignoriert. Der Server fügt bei der Ausgabe eines Tokens an den Client eine Signatur basierend auf der Nutzlast hinzu. Später werden die Nutzlast und die dazugehörige Signatur überprüft.

Die logische Frage ist: Was ist die Motivation, sich nicht mit verschlüsselten Inhalten zu befassen?

  1. Der einfachste Grund ist, dass davon ausgegangen wird, dass dies zum größten Teil ein gelöstes Problem ist. Wenn Sie sich zum Beispiel mit einem Client wie dem Webbrowser befassen, können Sie die JWT-Token in einem Cookie speichern, das secure + httpsOnly (kann nicht von Javascript gelesen werden + kann nicht von HTTP gelesen werden) und kommuniziert mit dem Server über einen verschlüsselten Kanal (HTTPS). Sobald Sie wissen, dass Sie einen sicheren Kanal zwischen Server und Client haben, können Sie JWT oder was auch immer Sie möchten sicher austauschen.

  2. Das hält die Sache einfach. Eine einfache Implementierung erleichtert die Übernahme, lässt aber auch jede Ebene das tun, was sie am besten kann (HTTPS übernimmt die Verschlüsselung).

  3. JWT ist nicht dazu gedacht, vertrauliche Daten zu speichern. Sobald der Server das JWT-Token empfangen und validiert hat, kann er die Benutzer-ID in seiner eigenen Datenbank nach zusätzlichen Informationen für diesen Benutzer (wie Berechtigungen, Postanschrift usw.) durchsuchen. Dies hält JWT klein und vermeidet versehentliche Informationsverluste, da jeder weiß, dass vertrauliche Daten in JWT nicht aufbewahrt werden.

Es unterscheidet sich nicht allzu sehr von der Funktionsweise von Cookies. Cookies enthalten häufig unverschlüsselte Nutzdaten. Wenn Sie HTTPS verwenden, ist alles in Ordnung. Wenn nicht, ist es ratsam, sensible Cookies selbst zu verschlüsseln. Andernfalls ist ein Man-in-the-Middle-Angriff möglich. Ein Proxyserver oder ISP liest die Cookies und spielt sie später erneut ab, wenn er vorgibt, Sie zu sein. Aus ähnlichen Gründen sollte JWT immer über eine sichere Schicht wie HTTPS ausgetauscht werden.

101
aleemb

Der Inhalt eines Json-Webtokens (JWT) ist nicht von Natur aus sicher, es gibt jedoch eine integrierte Funktion zum Überprüfen der Tokenauthentizität. Eine JWT besteht aus drei durch Punkte getrennten Hashes. Der dritte ist die Unterschrift. In einem öffentlichen/privaten Schlüsselsystem signiert der Aussteller die Tokensignatur mit einem privaten Schlüssel, der nur durch seinen entsprechenden öffentlichen Schlüssel verifiziert werden kann.

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

Es gibt zwei wichtige Schritte, um JWT sicher in einer Webanwendung zu verwenden: 1) Senden Sie sie über einen verschlüsselten Kanal, und 2) überprüfen Sie die Signatur sofort nach Erhalt. Die asymmetrische Natur der Kryptographie mit öffentlichen Schlüsseln ermöglicht die Überprüfung der JWT-Signatur. Ein öffentlicher Schlüssel überprüft, ob ein JWT mit seinem passenden privaten Schlüssel signiert wurde. Keine andere Tastenkombination kann diese Überprüfung durchführen, wodurch Identitätswechsel verhindert werden. Befolgen Sie diese beiden Schritte und wir können mit mathematischer Sicherheit die Echtheit eines JWT garantieren.

Lesen Sie weiter: Wie überprüft ein öffentlicher Schlüssel eine Signatur?

12
ThisClark

Nur der privateKey von JWT, der sich auf Ihrem Server befindet, entschlüsselt das verschlüsselte JWT. Diejenigen, die den privaten Schlüssel kennen, können das verschlüsselte JWT entschlüsseln.

Verstecken Sie den privaten Schlüssel an einem sicheren Ort auf Ihrem Server und teilen Sie niemandem den privaten Schlüssel mit.

1
sdfdsf sdf

Für die Leute, die sich teure Datenbankabfragen nicht leisten können, wie ich, besteht eine Möglichkeit, vertrauliche Daten (Benutzerrechte usw.) zu behalten, darin, diese Daten beim Generieren des JWT zu verschlüsseln und an das JWT-Token anzuhängen. (Behalten Sie den Verschlüsselungsschlüssel im Backend)

Wenn Sie die vertraulichen Informationen lesen möchten, können Sie das JWT-Token an das Backend senden, es entschlüsseln und die Informationen zurückerhalten. Auf diese Weise müssen Sie weder DB-Lookups durchführen noch die vertraulichen Informationen über JWT-Token im Frontend freigeben

0

Ich würde vorschlagen, einen Blick in JWE mit speziellen Algorithmen zu werfen, die in jwt.io zum Entschlüsseln nicht vorhanden sind

Referenzlink: https://www.npmjs.com/package/node-webtokens

jwt.generate('PBES2-HS512+A256KW', 'A256GCM', payload, pwd, (error, token) => {
  jwt.parse(token).verify(pwd, (error, parsedToken) => {
    // other statements
  });
});

Diese Antwort mag zu spät sein oder Sie haben den Weg bereits gefunden, aber ich hatte trotzdem das Gefühl, dass sie auch für Sie und andere hilfreich ist.

Ein einfaches Beispiel, das ich erstellt habe: https://github.com/hansiemithun/jwe-example

0