Welche Vorteile sollen das sein? Das schreibst Du hier leider nicht.

Einen klaren Nachteil sehe ich in der Verwendung von Benutzername und/oder Passwort in irgendeiner Art, die über einen seltenen einmaligen interaktiven Vorgang hinausgeht:

Ein Cookie kann gekapert werden. Egal, ob da ein Sessiontoken oder Benutzer/Passwort in irgendeiner Art drinnen steht. In letzterem Fall bekommt ein Angreifer gleich mal mehr relevante Informationen. Auch wenn die irgendwie gehasht darin vorliegen, dann hat er ja erstmal den Hash und kann in Ruhe sich daran abarbeiten, um mögliche Kandidaten der gehashten Werte zu errechnen.

Aber sollte ein Token gekapert werden, steht da keinerlei Information drin, außer eben der Token-ID. Es wird keine relevante Information nach draußen (zum Client) übertragen. Die Verknüpfung des Tokens mit relevanten Information erfolgt nur im Server-System.

Ein Token kann ganz einfach ungültig erklärt werden und ist damit nicht mehr benutzbar. Benutzernamen und Passwörter bleiben davon unberührt. Wie soll das bei Deinem Ansatz gehen, wenn die beiden oder nur einer davon in deiner Lösung verwendet wird?

Und Deine Lösung ist effektiv auch nichts anderes als ein Token. Ein Kennzeichen zum Nachweis, dass jemand für den Zugriff berechtigt ist. Ganz egal, ob Du das nun Token oder Cookie nennst. Nur dass Du "echte" Daten als Grundlage nehmen willst.

Ein Passwort wird einmal übertragen, verifiziert und danach wird der Zugriff über das Token geregelt.
Bei wichtigen Aktionen, wird das Passwort oder ein anderes Sicherheitsmerkmal abseits des Token nochmal abgefragt. Jeglicher "unkritische" Zugriff wird nur über das Token abgehandelt, was eben gemäß der Sicherheitsanforderungen rotiert werden sollte.

Um das Passwort irgendwie abzufangen, muss der Angreifer zur richtigen Zeit mitlesen. Genau zu der Eingabe.
Würde das jetzt bei jedem Zugriff in irgendeiner Art übertragen werden, erhöht sich die Zeitspanne für den Angreifer, um mitzulesen und Hinweise auf oder das Passwort sogar selbst zu ermitteln.

Ich meine, es ist ja nicht so, als hätte sich weltweit in all den Jahren niemand um dieses Thema vor Dir Gedanken gemacht. Raus gekommen ist die heute verbreitete Variante mit Sessions und Tokens und Abfrage zusätzlicher Parameter bei wichtigen Aktionen.

Und auch klar ist, dass eine Session- und/oder Tokenverwaltung wiederum serverseitig mehr Arbeit macht als ein "einfacher" Abgleich von Benutzername und Passwort. Das ist der Preis, der für die erhöhte Sicherheit gezahlt werden muss.

Wie ich in meiner ersten Antwort schrieb, muss man sich klar machen, was man schützen will und wieviel Aufwand das einem Wert ist.

Dieses Fundstück fand ich recht gut, weil es die Unterschiede zwischen allgemein verwendeten Mechanismen kompakt darstellt:
https://www.baeldung.com/cs/tokens-vs-sessions

Beim Lesen der Seite wurde mir auch wieder klar, dass die Nutzung der richtigen Begriffe wichtig ist. Ich bin mir der Unterschiede zwischen Session-basiert und Token-basiert (wie dort dargestellt) zwar bewusst, aber "Token" läuft bei mir als Synonym für Session-ID (Session-"Token") und eben auch Token... Es gibt feine Unterschiede zwischen beiden, aber auch Überschneidungen.

edit: im letzten Absatz eingefügt: (wie dort dargestellt) und (Session-"Token")
Last edited: 2024-05-15 16:32:50 +0200 (CEST)