Frage:
Would encrypting a signed JWT prove viable to secure claims payload?
scniro
2016-05-21 02:08:28 UTC
view on stackexchange narkive permalink

Ich arbeite an einer Server-Client-Webanwendung und stelle als Authentifizierungsschema base64-codierte json-Web-Token aus. Betrachten Sie das folgende Token ...

  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ  

Decoded als solche ...

  { "alg": "HS256", // header "typ": "JWT"}, {"sub": "1234567890", // payload "name": "John Doe", "admin": true}, HMACSHA256 ( base64UrlEncode (Header) + "." + base64UrlEncode (Nutzlast), 'geheim') // Signatur  

Mein Anliegen ist der Nutzlast Teil dieses Tokens. wo ich definierte Ansprüche liefern möchte, z "role": "readonly" . Ich mache mir Sorgen, dass diese Werte vom Endbenutzer nach ihrer Ausgabe sichtbar und manipuliert werden. Durch Ändern dieses Teils wird die Signaturprüfung nicht ungültig. Ich möchte keine Daten auf dem Server beibehalten, um ausgegebene Token erneut zu überprüfen / zu vergleichen. Ich möchte den Server vollständig zustandslos halten.

Ich dachte, ich könnte das Token signieren , verschlüsseln es über AES 256 und verwenden dies als mein "Token". Der Ablauf würde als solcher zusammengefasst ...

  1. Base64-codiertes Token generieren und signieren
  2. Token-Server-Seite über AES 256
  3. verschlüsseln Verschlüsseltes Token an Client ausgeben


  4. Anforderung empfangen, verschlüsseltes Token bereitgestellt

  5. Token-Serverseite entschlüsseln
  6. validiere base64-codierte Original -Token-Signatur (kann jetzt sicherstellen, dass Ansprüche nicht geändert wurden)
  7. ol>

    Meiner Meinung nach werden die Ansprüche (Nutzdaten) nicht angezeigt, und Manipulationen an diesem verschlüsselten Wert werden offensichtlich nicht wie erwartet serverseitig entschlüsselt. Meine Frage ist - ist das machbar? Ich konnte im Web nicht viel zum Verschlüsseln ganzer Token finden. Gibt es einen besseren Weg ?

Warum werden Ansprüche wie "Rolle" nicht in die Unterschrift aufgenommen?Ich glaube, dass der gesamte Inhalt des JWT unterschrieben ist.
@NeilSmithline danke für den Kommentar dazu.Ich würde das auch erwarten, aber wenn ich ein ursprünglich signiertes Token durch Ändern des Inhalts validiere, bekomme ich immer noch eine gültige Prüfung.Vielleicht funktioniert [node-jsonwebtoken] (https://github.com/auth0/node-jsonwebtoken) nicht wie erwartet oder ich vermisse etwas insgesamt.Ich hoffe du hast recht, ehrlich und ich vermisse nur etwas
In der [Zusammenfassung der Spezifikation] (https://tools.ietf.org/html/rfc7519) heißt es, dass Ansprüche "digital signiert oder integer geschützt" sind.Ich bin mir nicht sicher, was Ihr nächster Schritt sein soll.Vielleicht könnten Sie ein Beispiel des Tokens, das Sie ändern, in Ihre Frage aufnehmen?
@NeilSmithline Ah, Sie haben Recht, ich habe https://jwt.io/ verwendet, um den Inhalt zu ändern, aber ich habe nicht gesehen, dass es tatsächlich auch die Signatur ändert.Wäre es immer noch sinnvoll, das Token zu verschlüsseln, wenn ich vertrauliche Informationen im Token speichern möchte?
Sicher.Ich glaube, dass JWT die Verschlüsselung nativ unterstützt ([siehe Beispiel] (https://tools.ietf.org/html/rfc7519#page-26)).Dies zu verwenden ist wahrscheinlich besser als jede selbst entwickelte Lösung, die Sie sich einfallen lassen.Das heißt, das geht ein bisschen aus meiner Komfortzone heraus.
JWT verhindert, dass Dritte das Token ändern, da Sie die Integrität des Tokens und nicht des Inhalts überprüfen.Es ist daher nicht möglich, ein gültiges Token mit geänderten Daten zu generieren, es sei denn, Sie haben den geheimen Schlüssel.Versuchen Sie [diese Antwort] (https://softwareengineering.stackexchange.com/a/280311/59539).
Danke für die Tipps an alle.Als ich etwas über JWT erfuhr, verstand ich nicht ganz, dass das Ändern des Inhalts ihn ungültig machen würde, und im Allgemeinen möchten Sie keine vertraulichen Informationen in der Nutzlast speichern, da diese sowieso dekodiert und angezeigt werden sollen.
Einer antworten:
channel
2017-06-20 21:12:26 UTC
view on stackexchange narkive permalink

Ich glaube, Sie stellen zwei Fragen:

  1. macht das Ändern der Nutzlast die Signatur ungültig: TL; DR: ja
  2. gibt Ihnen das Hinzufügen von Verschlüsselung über JWT Authentizität des Inhalts: TL; DR: Verschlüsseln Sie sich nicht, verwenden Sie JWE!
  3. ol>

    Hier sind die Antworten ausführlicher:

    (1) Gemäß den Spezifikationen https://www.rfc-editor.org/rfc/rfc7515.txt

    Die Signatur eines signierten JWT (JWS) wird über den geschützten Header sowie die Nutzdaten berechnet:

    (siehe Abschnitt 5.1. Nachrichtensignatur oder MAC-Berechnung)

      Berechnen Sie die JWS-Signatur auf die Weise, die für den bestimmten Algorithmus definiert ist, der über den JWS-Signaleingang ASCII (BASE64URL ( UTF8 (JWS Protected Header)) || '.' || BASE64URL (JWS Payload)).  

    Wenn Sie also die Nutzdaten ändern, wird die Signatur ungültig.

    (2) Verschlüsseln Sie NICHT Ihre eigene JWT !! Es gibt eine aktuelle Spezifikation, die definiert, wie JWTs (JWE) verschlüsselt werden: https://www.rfc-editor.org/rfc/rfc7516.txt

    JWE verwendet authentifiziert Verschlüsselung, dh der Klartext wird zuerst verschlüsselt und anschließend wird eine Integritätsprüfung über den Chiffretext durchgeführt. Weitere Informationen zum Aussehen des Klartextes finden Sie in Abschnitt 5.1 der obigen Spezifikation.

    Es ist sicher möglich Speichern Sie Zugriffsrichtlinien in der Nutzlast Ihres JWT, wenn Sie verschlüsselte oder signierte Formate verwenden. Möglicherweise möchten Sie verschlüsselt verwenden, wenn Sie nicht möchten, dass der Client oder andere Parteien Kenntnis von den Richtliniendaten haben. Wenn es Ihnen egal ist, wer es lesen kann, und Sie sich nur darum kümmern, wer die Werte ändern kann, verwenden Sie nur Signaturen.

    Denken Sie jedoch daran, dass die Leistung umso größer ist, je mehr Sicherheit Sie hinzufügen auf was benötigt wird.

    Schlussbemerkung: Die Schlüsselverwaltung der Signatur- und Verschlüsselungsschlüssel wird ebenfalls zu einem wichtigen Thema, das Sie berücksichtigen sollten, da am Ende des Tages jeder, der Zugriff auf die Schlüssel hat, Ihr JWE entschlüsseln oder die Signatur Ihres JWS ändern kann. Stellen Sie daher sicher, dass Sie gute Sicherheitspraktiken anwenden, in denen Sie die tatsächlichen Schlüssel speichern, wer Zugriff darauf hat und wie sie verwendet und gespeichert werden.

Danke für die Antwort!Obwohl es spät ist, stimme ich jetzt jedem Punkt zu, den Sie erwähnt haben, seit ich diese Frage gestellt habe.In meinem Fall reicht es für mich aus, sicherzustellen, dass die Signatur ungültig wird, wenn das Token manipuliert wird.Ich muss keine vertraulichen Informationen mehr im Token speichern, aber ja, ein JWE würde ich verwenden, wenn ich das noch brauche!


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...