Ablauf der Nutzerauthentifizierung — von der Registrierung zur Sitzung
Ein Ablauf der Nutzerauthentifizierung, interaktiv dargestellt: Kontoerstellung, Hashen und Speichern der Zugangsdaten, Anmeldung, Sitzung und geprüfte Anfragen.
Ein Ablauf der Nutzerauthentifizierung ist der Weg von der Kontoerstellung bis dahin, dass jede spätere Anfrage vertrauenswürdig ist: Zugangsdaten werden vor dem Speichern gehasht, bei der Anmeldung geprüft, und danach steht ein Sitzungstoken für das Passwort ein.
Ablauf der Nutzerauthentifizierung — von der Registrierung zur Sitzung
Die interaktive FlowJam-Zeichenfläche zu dieser Erklärung — jede Bahn, jede Zeile und jeder Pfeil oben gehört zu einem echten QueryChart-Diagramm, das Sie öffnen und bearbeiten können.
So lesen Sie diese Darstellung
- Lesen Sie die drei Spalten von links nach rechts: Registrierung, Anmeldung, Sitzung.
- Die vier Bahnen sind die Beteiligten, und das Passwort verlässt die oberen drei nie — nur Hashes erreichen die Bahn Datenbank.
- Die Entscheidung „Hash stimmt mit dem gespeicherten überein?“ teilt die Anmeldung in den Sitzungspfad und die Ablehnung „Anmeldung abgelehnt“.
Registrierung
„Nutzer erstellt ein Konto“ und „Client sendet E-Mail und Passwort“ speisen „Auth-Dienst hasht das Passwort“ — den Moment, in dem das Passwort nicht mehr zurückgewinnbar ist. „Gehashte Zugangsdaten werden in der Datenbank gespeichert“ ist das Ende der Registrierung: Die Datenbank hält nun einen gesalzenen Hash, und der Kommentar dazu erklärt, dass der Dienst den Klartext nicht zurückgewinnen kann — genau darum wird gehasht.
Anmeldung
„Nutzer meldet sich mit Zugangsdaten an“ und „Client leitet sie an den Auth-Dienst weiter“ wiederholen die erste Hälfte des Weges, und „Hash stimmt mit dem gespeicherten überein?“ ist die Prüfung: Das eingehende Passwort wird auf dieselbe Weise gehasht und verglichen. Der Zweig „Nein“ endet bei „Anmeldung abgelehnt“; der Zweig „Ja“ geht weiter zur Erstellung der Sitzung.
Sitzung
„Auth-Dienst erstellt eine Sitzung“ stellt das Token aus, das das Passwort ersetzt, „Client speichert das Sitzungstoken“ bringt es zum Client, und „Geschützte Anfragen tragen das Token; Server prüft es“ ist der Dauerzustand des Systems — jede geschützte Anfrage weist sich mit dem Token aus. „Zugriff für die Sitzung gewährt“ schließt den Ablauf: Der Nutzer ist für die Dauer der Sitzung authentifiziert, nicht für eine einzelne Anfrage.
Wichtige Zusammenhänge und Erkenntnisse
- Passwörter werden vor dem Speichern gehasht — die Datenbank hält einen gesalzenen Einweg-Hash, nie den Klartext.
- Die Anmeldung vergleicht Hashes, der Auth-Dienst selbst kann das gespeicherte Passwort also nicht zurückgewinnen.
- Das Sitzungstoken ersetzt für alle folgenden Anfragen das Passwort, und erst das macht Authentifizierung in großem Maßstab praktikabel.
- Speicherung und Prüfung sind getrennte Zuständigkeiten in getrennten Bahnen, sodass beide für sich geschützt werden können.
- Der Ablauf hat dieselbe Form, ob das Token eine Serversitzung oder ein JWT ist — die Mechanik des Tokens zeigt die Darstellung zu JWT.
Wann Sie diese Darstellung nutzen
- Einem neuen Team die sichere Form der Authentifizierung zeigen, bevor es seine erste Anmeldung entwirft.
- Einen Anmeldeablauf auf die klassischen Fehler prüfen — Klartext speichern, Klartext vergleichen, dem Client vertrauen.
- Ein Gespräch über die Zwei-Faktor-Authentifizierung und ihren Platz im Ablauf auf eine gemeinsame Grundlage stellen.
So funktioniert es
Benennen Sie die Beteiligten auf Ihr System um
Ersetzen Sie Client-App und Auth-Dienst durch Ihre echten Bestandteile — Ihre Web-App, Ihren Identitätsanbieter — und ergänzen Sie die, die im allgemeinen Diagramm fehlen.
Ergänzen Sie die Zwei-Faktor-Authentifizierung
Fügen Sie bei der Anmeldung einen Schritt für den zweiten Faktor ein, zwischen der Hash-Prüfung und der Erstellung der Sitzung, mit einem eigenen Zweig für dessen Prüfung.
Zeigen Sie den Pfad zum Zurücksetzen des Passworts
Ergänzen Sie einen Zweig an der Anmeldeentscheidung — Passwort vergessen, Reset-Token, neues Passwort setzen — der jeweils in einem expliziten Zustand endet.
Vermerken Sie den Lebenszyklus des Tokens
Notieren Sie am Sitzungskasten die Regeln für Ablauf, Widerruf und Erneuerung Ihres Tokens, und verweisen Sie auf die Darstellung zu JWT, wenn Sie JWTs ausstellen.
Häufig gestellte Fragen
Wie speichert man Passwörter sicher?
Speichern Sie nie das Passwort selbst. Speichern Sie einen gesalzenen Hash — eine Einwegfunktion, angewandt auf das Passwort plus ein zufälliges Salt — und verwerfen Sie den Klartext. Bei der Anmeldung hashen Sie das eingehende Passwort auf dieselbe Weise und vergleichen die Hashes. Leakt die Datenbank, bekommt der Angreifer Hashes, die er nicht umkehren kann — genau diese Eigenschaft zeigen die Hash-Kästen der Darstellung.
Was ist der Unterschied zwischen Hashen und Verschlüsselung?
Verschlüsselung ist umkehrbar — mit dem Schlüssel gewinnen Sie den ursprünglichen Wert zurück. Hashen ist ein Einwegverfahren — es gibt keinen Schlüssel und keinen Weg zurück. Für Passwörter wollen Sie das Hashen, denn Sie brauchen den Klartext nie wieder, nur die Möglichkeit zu prüfen. Deshalb heißt es in der Darstellung „hasht“ und nicht „verschlüsselt“; Passwörter zu verschlüsseln ist eine verbreitete und gefährliche Verwechslung.
Wie ersetzt ein Sitzungstoken das Passwort?
Nach einer erfolgreichen Anmeldung erstellt der Auth-Dienst eine Sitzung und übergibt dem Client ein Token — einen Zufallswert oder ein signiertes JWT —, das für den authentifizierten Nutzer steht. Geschützte Anfragen tragen das Token, und der Server prüft es, statt erneut nach dem Passwort zu fragen. Das macht Authentifizierung bei wiederholten Anfragen praktikabel, und deshalb ist der Ablauf des Tokens die eigentliche Sicherheitsgrenze.
Wo passt die Zwei-Faktor-Authentifizierung in diesen Ablauf?
Sie ist eine zusätzliche Prüfung bei der Anmeldung, nach der Prüfung des Passworts und vor der Erstellung der Sitzung: Der Nutzer liefert einen zweiten Faktor — einen Einmalcode, eine Authenticator-App, einen Hardware-Schlüssel. Die Anmeldespalte der Darstellung ist die Stelle, an der dieser Schritt einsetzt. Am Hashen und an der Sitzungsmechanik ändert sich nichts; die eine Entscheidung „Hash stimmt mit dem gespeicherten überein?“ bekommt lediglich einen zweiten Nachweis.
Diese Darstellung in QueryChart (FlowJam) bearbeiten
Öffnen Sie genau diese Zeichenfläche zur Authentifizierung als eigenes Diagramm, benennen Sie die Beteiligten auf Ihr System um, und ergänzen Sie Ihre echten Kontrollen.