JWT, zustandslose Authentifizierung und Sicherheit

Question

Ich arbeite an einer Anwendung, wo Skalierbarkeit ein großes Anliegen ist. In der Vergangenheit habe ich Session-basierte Authentifizierung verwendet, entschied mich aber dieses Mal mit einem zustandslosen Server zu gehen, um horizontale Skalierung zu erleichtern.

Ich bin kein Sicherheitsexperte, aber bei der Untersuchung von JWTs schien es, dass diese sehr unsicher sind. Der ganze Grund, warum wir Passwörter hacken, besteht darin, dass der Angreifer, wenn unsere Datenbank kompromittiert ist, nicht die Identität eines Benutzers annehmen kann. Mit JWT speichern wir ein Geheimnis auf dem Server. Wenn der Angreifer Zugriff auf das Geheimnis erhält, kann er sich nicht als ein beliebiger Benutzer ausgeben? Bedeutet dies nicht, dass die Verwendung von JWTs dasselbe Sicherheitsniveau wie das Speichern von Klartextpasswörtern hätte?

Ich habe gelesen, dass Leute reddis manchmal benutzen werden, um Referenz-JWTs zu kreuzen, aber dann ist der Server nicht zustandslos, und ich sehe den Vorteil der Verwendung von JWTs überhaupt nicht.

Könnte jemand helfen, dieses Problem für mich zu klären?

Answer 1

Sitzungsbasierte Authentifizierungssysteme, zumindest solche, die es Wert sind zu verwenden, speichern auch ein Geheimnis auf dem Server. Genau wie das JWT wird das Geheimnis verwendet, um die Daten zu signieren, die in dem Cookie gespeichert sind, das die sitzungsbasierte Authentifizierung verwendet. Das ist also nicht anders als ein JWT.

All dies hat nichts mit Passwortspeicherung zu tun, da das Passwort nur verwendet wird, wenn Sie kein Cookie/JWT haben.

EDIT:

Nicht das, was Sie sicher, Redis in Verbindung mit einem JWT sagen über die Verwendung ... Was in Redis gespeichert wird, das Token? Das scheint sinnlos, da der Server nur das Geheimnis braucht, um das Token zu entschlüsseln.

Hier sind einige der Vorteile auf einen mit einem JWT:

• Es ist staatenlos, wie Sie bereits
• erwähnt haben Gegenstand Es ist nicht zu CSRF/XSRF Angriffe. Diese Angriffe funktionieren, indem Sie Ihren Browser dazu bringen, das Cookie an einen Server zu senden, der das Cookie nicht generiert hat. Dies kann nicht mit einem JWT b/c geschehen. Der Browser sendet den JWT nicht automatisch wie bei Cookies.
• JWT sind standardized. Es gibt einen genau definierten Weg, um sie zu generieren, was bedeutet, dass JWTs portabler sind und der Prozess von der Sicherheitsgemeinschaft überprüft wurde.

Answer 2

Der Server ein JWT Token (Ressource-Server) Zugang braucht nicht zu jedem Geheimnis raubend. Alles, was sie benötigt, ist der öffentliche Schlüssel , der zu dem privaten Schlüssel gehört, mit dem das Token digital signiert ist.

Der Autorisierungsserver, der das Token ausgibt, muss seinen Signaturschlüssel offensichtlich geheim halten. Aber das Schöne an Token-basierter Authentifizierung ist, dass dieser Server von einer externen Partei mit viel mehr Ressourcen/Know-how erstellt werden kann, um diese Dinge geheim zu halten (Google, Facebook, Microsoft usw.).

Der Ressourcenserver muss die Datenbank nicht überprüfen, um das Token zu validieren, wie dies bei Benutzername und Kennwort erforderlich wäre. Dies hilft der Skalierbarkeit des Systems und entfernt einen einzigen Fehlerpunkt.

Wenn ein Client/Benutzer das JWT-Token verliert, kann ein Angreifer die Identität des Clients/Benutzers annehmen, bis das Token abläuft. Ein guter Grund, die Lebensdauer der Token kurz zu halten.

Ich sehe nicht den Punkt der Speicherung von JWT-Token in einem Reddis-Cache. Es gibt keine Notwendigkeit, Tokens zwischen Servern zu teilen, da jeder Anruf mit einem Token im HTTP-Header Authorization kommt. Das Speichern in einem Cache erhöht nur das Risiko, dass Token gestohlen werden.