PHP-Anmeldung: Passwörter prüfen und Sitzungen begrenzen

Eine Anmeldung besteht aus mehreren getrennten Entscheidungen: Passt die Passworteingabe zu einem gespeicherten Prüfnachweis? Darf das betreffende Konto überhaupt verwendet werden? Welche Sitzung erhält anschließend die bestätigte Identität? Wie lange gilt diese Zuordnung und wie wird sie wieder aufgehoben? Wer diese Fragen getrennt umsetzt, kann Fehler gezielter erkennen als mit einer einzigen Abfrage nach einem Benutzernamen.

Der folgende Leitfaden verbindet Passwortspeicherung und Sitzungsverwaltung mit einem tatsächlich ausgeführten PHP-Beispiel. Die Bausteine wurden mit künstlichen Kontodaten geprüft. Sie bilden einen bewusst begrenzten Lernumfang. Eine vollständige betriebliche Anmeldung benötigt zusätzlich unter anderem Schutz vor massenhaften Versuchen, Kontowiederherstellung, passende Berechtigungen und gegebenenfalls zusätzliche Authentisierungsfaktoren. Diese Aufgaben werden nicht durch einen erfolgreichen Passwortvergleich erledigt.

Identität und Berechtigung getrennt beantworten

Authentisierung beantwortet, ob ein vorgelegter Nachweis zu einer Identität passt. Autorisierung entscheidet, ob diese Identität eine bestimmte Handlung an einem bestimmten Objekt ausführen darf. Ein angemeldetes Konto darf deshalb nicht automatisch jede Rechnungsdatei lesen oder jede Kundennummer aus einer Adresse übernehmen. Diese Prüfung gehört bei jeder geschützten Fachaktion auf den Server.

Eine Sitzung stellt den Zusammenhang zwischen mehreren Anfragen her. Der Browser besitzt dafür normalerweise eine zufällige Kennung. Die bestätigte Kontoidentität und weitere Zustände liegen serverseitig. Ein Cookie mit einer frei änderbaren Kontonummer wäre kein Ersatz. Ebenso wenig darf ein Formularfeld mit einer angeblichen Administratorrolle als vertrauenswürdiger Nachweis verwendet werden.

Für eine bestehende Anwendung lohnt sich zuerst der Blick auf deren Identitätsverwaltung. Ein etabliertes Rahmenwerk oder ein passender Identitätsdienst kann Wartung und Fehlerbehandlung bereits unterstützen. Eigene kryptografische Verfahren sind für eine gewöhnliche Unternehmensanwendung keine sinnvolle Abkürzung. Das hier erläuterte Beispiel dient dem Verständnis konkreter Übergänge und nicht dem Austausch einer funktionierenden Anmeldung ohne Migrationsplan.

Passwörter als prüfbare Hashwerte speichern

PHP stellt mit password_hash eine geeignete Schnittstelle zur Passwortableitung bereit. Im Beispiel wird Argon2id ausdrücklich ausgewählt. Der PHP-Build muss diesen Algorithmus unterstützen. Das wurde für die verwendete Laufzeit geprüft. Eine Anwendung sollte eine fehlende Voraussetzung erkennen und nicht stillschweigend auf einen beliebigen schnellen Hash wechseln.

Das gespeicherte Ergebnis enthält die zur Prüfung notwendigen Angaben zu Algorithmus, Parametern und Salt. Der Salt wird von der Funktion erzeugt. Er ist kein zusätzliches Passwort und muss nicht geheim sein. Zwei Konten mit derselben Passphrase sollen unterschiedliche gespeicherte Hashwerte erhalten. Das erschwert die Wiederverwendung vorberechneter Angriffe und ist im Beispiel mit tatsächlich erzeugten Hashwerten geprüft.

Eine Verschlüsselung mit einem später wieder auslesbaren Passwort ist für die gewöhnliche Anmeldung ebenfalls das falsche Ziel. Der Dienst muss die Übereinstimmung prüfen können, ohne das ursprüngliche Passwort zurückzugeben. Ein schneller allgemeiner Hash wie ein einfacher SHA-256-Aufruf ist wiederum nicht als Ersatz für eine absichtlich aufwendige Passwortableitung gedacht.

Die Kostenparameter bewusst wählen

Die OWASP-Empfehlung zur Passwortspeicherung nennt für Argon2id unter anderem eine Mindestkonfiguration mit 19 MiB Speicher, zwei Durchläufen und einem Parallelitätsgrad von eins. Das Beispiel verwendet dafür die PHP-Optionen mit 19456 KiB Speicher. Diese Einheiten dürfen nicht miteinander verwechselt werden.

Die Konfiguration ist ein nachvollziehbarer Ausgangspunkt und keine Aussage über die verfügbare Kapazität eines beliebigen Servers. Bei vielen gleichzeitigen Anmeldungen addiert sich der Ressourcenbedarf. Eine Einführung muss legitime Last, Angriffsversuche und verfügbare Grenzen gemeinsam betrachten. Der vorliegende Prüflauf enthält keine Lastmessung und keine Behauptung über eine erreichbare Zahl von Anmeldungen pro Sekunde.

Bei einem Bestand mit anderen Algorithmen ist eine eigene Migrationsentscheidung nötig. Insbesondere die bekannte Eingabegrenze von bcrypt darf nicht durch stilles Abschneiden langer Passwörter kaschiert werden. Die hier gezeigte Prüfkomponente erwartet ausdrücklich Argon2id-Datensätze. Sie ist kein universeller Importer für beliebige alte Passwortformate.

Passworteingaben unverändert vergleichen

password_verify prüft die Eingabe gegen den gespeicherten Hash. Ein erneutes Hashen mit einem neuen zufälligen Salt und anschließender Zeichenkettenvergleich würde die richtige Eingabe regelmäßig nicht erkennen. Die vorhandenen Parameter müssen aus dem gespeicherten Prüfnachweis verwendet werden.

Eine Passphrase sollte bei der Anmeldung nicht nebenbei durch das Entfernen von Leerzeichen oder eine Umwandlung der Großschreibung verändert werden. Das Beispiel erhält die eingegebenen Bytes. Seine Tests umfassen Leerzeichen, Unicode und unterschiedliche Zeichen jenseits der ersten 72 Bytes. Diese Aussagen beschreiben den getesteten Argon2id-Pfad und keine Eigenschaft sämtlicher historischer Verfahren.

Das Verarbeitungslimit von 1024 Bytes ist eine technische Grenze dieses Lernbausteins. Es wird ausdrücklich abgelehnt statt gekürzt. Daraus entsteht keine Empfehlung, neue Passwörter mit nur einem Zeichen zuzulassen. Regeln für die Registrierung, lange nutzbare Passphrasen und das Prüfen bekannter kompromittierter Passwörter sind gesondert festzulegen. Eingabeprüfung bei der Anmeldung und Auswahlregeln bei der Registrierung erfüllen unterschiedliche Aufgaben.

Fehlerantworten und unbekannte Konten behandeln

Ein Anmeldeformular sollte einem fremden Besucher nicht unnötig verraten, ob ein bestimmtes Konto vorhanden oder gesperrt ist. Die OWASP-Hinweise zur Authentisierung behandeln deshalb neben dem sichtbaren Text auch Statuscodes und Unterschiede im Ablauf. Im ausgeführten Beispiel erhalten ein falsches Passwort, ein unbekanntes Konto und ein gesperrtes Konto denselben Status 401 mit derselben Fehlermeldung.

Für ein unbekanntes Konto wird ein gültiger serverseitig vorbereiteter Dummy-Hash geprüft. So entfällt der offensichtliche Unterschied zwischen sofortigem Abbruch und aufwendiger Passwortprüfung. Dieser Hash wird nicht bei jeder Anfrage neu erzeugt. Er darf nicht aus einem Formularfeld stammen. Selbst wenn eine Eingabe zufällig zu diesem Dummy-Hash passt, darf daraus keine Kontoidentität entstehen.

Eine solche Maßnahme beweist keine exakt identische Gesamtlaufzeit. Datenbankzugriff, verschiedene Hashparameter, Infrastruktur und andere Prüfungen können Unterschiede verursachen. Der Bericht bestätigt deshalb nur die konkret ausgeführten Funktionen und gleichen äußeren Fehlerantworten. Er behauptet keinen vollständigen Nachweis gegen zeitbasierte Kontoermittlung.

Veraltete Hashparameter nach erfolgreicher Prüfung erneuern

password_needs_rehash vergleicht einen gespeicherten Hash mit den gewünschten Parametern. Die Frage wird nach einer erfolgreichen Passwortprüfung gestellt. Falls nötig, wird aus der gerade bestätigten Passworteingabe ein neuer Hash erzeugt. Der alte Hashwert selbst wird nicht als angebliches Passwort erneut gehasht.

Die Beispielkomponente gibt einen Ersatzwert zurück. Sie speichert ihn nicht. In einer echten Anwendung gehört das Aktualisieren zum Kontospeicher und muss konkurrierende Änderungen berücksichtigen. Ein an die alte Fassung gebundenes Update kann beispielsweise verhindern, dass ein inzwischen geändertes Passwort durch einen verspäteten Anmeldevorgang überschrieben wird. Die passende Transaktion hängt vom verwendeten Speicher ab.

Ein fehlgeschlagener Anmeldeversuch darf diesen Mechanismus nicht zur Änderung des Kontos verwenden. Die Tests beginnen mit einem künstlichen Argon2id-Hash mit schwächeren Parametern und prüfen sowohl die Rückgabe des neuen Hashwerts als auch dessen tatsächliche Verifizierbarkeit. Eine reale Kontomigration wurde nicht ausgeführt.

Sitzungscookies vor dem Start konfigurieren

Die PHP-Dokumentation zur Sitzungsverwaltung beschreibt wichtige Voraussetzungen wie ausschließliche Cookieverwendung und den strikten Modus. Das Beispiel aktiviert diese Einstellungen vor dem Sitzungsstart. Eine vom Besucher frei erfundene noch nicht initialisierte Kennung wird beim verwendeten Dateispeicher nicht als vorhandene Sitzung übernommen.

Das Cookie heißt im Beispiel __Host-azsid. Es wird mit Secure, HttpOnly, SameSite=Lax und dem Pfad / gesetzt. Eine Domainangabe wird nicht ausgegeben. Die Dokumentation zu Set-Cookie erläutert die zusätzlichen Regeln des Host-Präfixes für unterstützende Browser. Die tatsächlichen Attribute wurden im isolierten Browserkontext überprüft.

HttpOnly verhindert das direkte Auslesen des Cookies durch gewöhnliches Seitenskript. Es verhindert nicht, dass ein eingeschleustes Skript im Browser Anfragen mit vorhandenen Cookies auslöst. Secure ersetzt wiederum keine verpflichtende HTTPS-Konfiguration der Anwendung. Ein Sitzungscookie ohne festes Ablaufdatum ist auch keine zuverlässige Zusicherung, dass nach jedem Schließen des Browsers alle Sitzungen beendet sind.

Bei erfolgreicher Anmeldung die Kennung wechseln

Eine bestätigte Identität gehört nicht nachträglich in eine bereits bekannte anonyme Sitzungskennung. Die Funktion session_regenerate_id ermöglicht den Wechsel. Im Beispiel wird zunächst der alte anonyme Datensatz als nicht mehr verwendbar markiert. Danach entsteht eine neue Kennung und ausschließlich diese neue Sitzung erhält die Kontoidentität.

Der alte Datensatz wird dabei nicht sofort gelöscht. Die Markierung verhindert seine weitere Verwendung im Beispiel. Der neue Datensatz erhält außerdem einen neuen CSRF-Token. Die Tests übernehmen die vorherige Kennung gezielt in einen zweiten Browserkontext und prüfen, dass darüber kein geschützter Zugriff möglich wird.

Dieser klar begrenzte Übergang beschreibt die erstmalige Anmeldung aus einem anonymen Zustand. Für die Rotation bereits authentifizierter Sitzungen, unzuverlässige Netze oder gleichzeitig laufende Anfragen muss ein umfassenderes Lebenszykluskonzept hinzukommen. Sofortiges Löschen alter Sitzungsdaten ist keine allgemeine Lösung für solche Rennen. Bei mehreren Servern müssen Speicher und Widerruf ebenfalls gemeinsam funktionieren.

Zustandsänderungen mit Methode und CSRF-Prüfung schützen

Die gezeigte Integration akzeptiert Anmeldung und Abmeldung nur per POST. Ein einfacher Aufruf einer Adresse per GET meldet niemanden an oder ab. Beide Aktionen verlangen außerdem einen zufälligen Token aus der jeweiligen Sitzung. Ein fehlender oder nicht passender Wert führt vor der Aktion zu einer Ablehnung.

Der OWASP-Leitfaden zu CSRF erklärt diesen sitzungsgebundenen Tokenansatz und empfiehlt vorhandene Schutzmechanismen eines Rahmenwerks zu nutzen. Der Token gehört in einen vorgesehenen Anfragebestandteil und nicht in eine Adresse oder ein Analyseprotokoll. Seine zufällige Erzeugung ist wichtiger als ein besonders kreativer Feldname.

Im Beispiel wird der frühere Token nach der Anmeldung absichtlich nochmals zur Abmeldung verwendet. Die Anfrage wird abgelehnt und die gültige Sitzung bleibt bestehen. Erst der neue richtige Token bewirkt die Abmeldung. Diese Beobachtung belegt einen konkreten Schutzpfad. Sie ersetzt weder eine vollständige Prüfung aller Endpunkte noch Schutz vor eingeschleustem Seitenskript.

Inaktivität und absolute Laufzeit serverseitig prüfen

Ein Browsercookie und die Speicherbereinigung von PHP bestimmen nicht allein, wie lange eine Anmeldung gelten soll. Das Beispiel speichert den Beginn der bestätigten Sitzung und den letzten erfolgreich geprüften geschützten Zugriff. Bei jeder entsprechenden Anfrage werden beide Zeitabstände mit einer serverseitigen Uhr geprüft.

Für den Lernfall gelten 900 Sekunden Inaktivität und 28800 Sekunden absolute Laufzeit. Das sind ausdrücklich gewählte Beispielwerte. Ein System mit besonders sensiblen Funktionen kann andere Grenzen und eine erneute Bestätigung wichtiger Aktionen benötigen. Ein dauerhaft laufender Hintergrundabruf sollte nicht unbemerkt die fachlich gewünschte Inaktivitätsregel aushebeln.

Die Uhr des Tests wurde im privaten Prüfaufbau gesteuert. Kein Anfrageparameter darf in der echten Anwendung den maßgeblichen Zeitpunkt liefern. Ebenso wenig sollte ein negativer Zeitabstand durch eine Uhrabweichung stillschweigend eine verlängerte Anmeldung ermöglichen. Die Komponente lehnt unplausible Zeitfolgen ab.

Die geprüften PHP-Bausteine

Der vollständige folgende Baustein erwartet vertrauenswürdige Kontodatensätze und eine korrekt konfigurierte Sitzungsablage. Vor dem Aufruf zur Anmeldung muss die Integration Methode, CSRF-Token und Zugangsdaten geprüft haben. Die Komponenten wurden gemeinsam mit einer isolierten Integration ausgeführt. Eine Produktanwendung sollte diese Grenzen durch ihre eigene zentrale Anmeldeschicht einhalten.

<?php
declare(strict_types=1);

const PASSWORD_OPTIONS = ['memory_cost' => 19456, 'time_cost' => 2, 'threads' => 1];
const IDLE_SECONDS = 900;
const ABSOLUTE_SECONDS = 28800;

function createPasswordHash(string $password): string
{
    if ($password === '' || strlen($password) > 1024) {
        throw new InvalidArgumentException('Passworteingabe ausserhalb des Umfangs.');
    }
    return password_hash($password, PASSWORD_ARGON2ID, PASSWORD_OPTIONS);
}

// $account and $dummyHash come from trusted server-side storage.
// Registration policy and persistence of a replacement hash are separate tasks.
function verifyAccount(?array $account, mixed $password, string $dummyHash): ?array
{
    if (!is_string($password) || $password === '' || strlen($password) > 1024) {
        return null;
    }
    $hash = $account['hash'] ?? $dummyHash;
    if (!is_string($hash) || password_get_info($hash)['algoName'] !== 'argon2id') {
        throw new LogicException('Dieses Beispiel erwartet Argon2id-Datensaetze.');
    }
    $matches = password_verify($password, $hash);
    if ($account === null || !$matches || ($account['active'] ?? false) !== true) {
        return null;
    }
    if (!is_int($account['id'] ?? null) || $account['id'] < 1) {
        throw new LogicException('Ungueltiger serverseitiger Kontodatensatz.');
    }
    return [
        'id' => $account['id'],
        'replacement_hash' => password_needs_rehash($hash, PASSWORD_ARGON2ID, PASSWORD_OPTIONS)
            ? createPasswordHash($password) : null,
    ];
}

// Call before output. The external application MUST enforce HTTPS.
function beginSession(): bool
{
    if (session_status() !== PHP_SESSION_NONE) {
        throw new LogicException('Sitzung bereits gestartet.');
    }
    ini_set('session.use_strict_mode', '1');
    ini_set('session.use_only_cookies', '1');
    ini_set('session.use_trans_sid', '0');
    session_name('__Host-azsid');
    session_set_cookie_params([
        'lifetime' => 0, 'path' => '/', 'domain' => '',
        'secure' => true, 'httponly' => true, 'samesite' => 'Lax',
    ]);
    if (!session_start()) {
        throw new RuntimeException('Sitzung konnte nicht gestartet werden.');
    }
    if (isset($_SESSION['retired_at'])) {
        return false;
    }
    $_SESSION['csrf'] ??= bin2hex(random_bytes(32));
    return true;
}

function validCsrf(mixed $token): bool
{
    return is_string($token) && strlen($token) === 64
        && is_string($_SESSION['csrf'] ?? null)
        && hash_equals($_SESSION['csrf'], $token);
}

// Only call after successful credential verification and a valid login CSRF token.
// $now is server time, never a time supplied in the request.
function establishLogin(int $accountId, int $now): void
{
    if ($accountId < 1 || $now < 1 || session_status() !== PHP_SESSION_ACTIVE
        || isset($_SESSION['retired_at']) || isset($_SESSION['auth'])) {
        throw new LogicException('Anmeldeuebergang nicht zulaessig.');
    }
    $_SESSION['retired_at'] = $now;
    if (!session_regenerate_id(false)) {
        throw new RuntimeException('Sitzungswechsel fehlgeschlagen.');
    }
    $_SESSION = [
        'csrf' => bin2hex(random_bytes(32)),
        'auth' => ['id' => $accountId, 'created_at' => $now, 'last_seen' => $now],
    ];
}

function authenticatedUser(int $now): ?int
{
    $auth = $_SESSION['auth'] ?? null;
    if (isset($_SESSION['retired_at']) || !is_array($auth)) {
        return null;
    }
    $valid = is_int($auth['id'] ?? null) && $auth['id'] > 0
        && is_int($auth['created_at'] ?? null) && is_int($auth['last_seen'] ?? null)
        && $auth['created_at'] > 0 && $auth['created_at'] <= $auth['last_seen']
        && $auth['last_seen'] <= $now
        && $now - $auth['last_seen'] < IDLE_SECONDS
        && $now - $auth['created_at'] < ABSOLUTE_SECONDS;
    if (!$valid) {
        unset($_SESSION['auth'], $_SESSION['csrf']);
        $_SESSION['retired_at'] = $now;
        return null;
    }
    $_SESSION['auth']['last_seen'] = $now;
    return $auth['id'];
}

// The caller must require POST and a valid CSRF token first.
function retireSession(int $now): void
{
    $_SESSION = ['retired_at' => $now];
    setcookie(session_name(), '', [
        'expires' => time() - 3600, 'path' => '/', 'domain' => '',
        'secure' => true, 'httponly' => true, 'samesite' => 'Lax',
    ]);
}

Abmeldung als serverseitigen Zustandswechsel behandeln

Bei der Abmeldung entfernt das Beispiel die bestätigte Identität aus dem aktuellen Sitzungsdatensatz und markiert ihn als stillgelegt. Zusätzlich wird das zugehörige Cookie mit passenden Eigenschaften abgelaufen gesetzt. Das bloße Löschen eines Browsercookies würde eine zuvor kopierte Kennung auf dem Server nicht automatisch ungültig machen.

Der Prüflauf versucht deshalb ausdrücklich, die abgemeldete Kennung in einem anderen Browserkontext wiederzuverwenden. Der geschützte Zugriff bleibt verweigert. Eine Funktion „überall abmelden“ wäre dagegen ein eigener Mechanismus über alle zu einem Konto gehörenden Sitzungen. Sie ist in dieser einzelnen Sitzungsablage nicht enthalten und darf nicht allein aus dem Abmeldeknopf abgeleitet werden.

Den tatsächlichen Prüfumfang einordnen

Ausgeführt wurden 68 Komponentenprüfungen und 81 Prüfungen mit Edge über eine isolierte HTTPS-Verbindung. Die Komponentenfälle betreffen unter anderem Hashwerte, Eingabegrenzen, Parametererneuerung, Token und Zeitgrenzen. Die Browserfälle prüfen Cookieeigenschaften, Methoden, Fehlerantworten, Kennungswechsel, Wiederverwendung und Ablauf. Insgesamt wurden 149 konkrete Prüfungen bestanden.

Die HTTPS-Umgebung verwendet ausschließlich ein künstliches Konto und ein selbstsigniertes Prüfzertifikat auf der Rückschleifenadresse. Der isolierte Browserkontext akzeptiert dieses Zertifikat nur für den Test. Daraus folgt kein Nachweis über die Zertifikatskette oder Transportkonfiguration einer produktiven Webseite. Ebenso wenig wurden verteilte Sitzungen, Angriffsbelastung oder gleichzeitig konkurrierende Anfragen nachgewiesen.

Checkliste für eine betriebliche Einführung

Vor einer Veröffentlichung muss außerdem klar sein, wie Anmeldeversuche begrenzt werden. Eine bloße Begrenzung pro IP-Adresse erfasst verteilte Versuche gegen dasselbe Konto nur unvollständig. Eine starre dauerhafte Kontosperre lässt sich wiederum gegen die eigentliche Person verwenden. Ein betriebliches Konzept verbindet deshalb geeignete Kontobezüge, begrenzte Zeitfenster, zusätzliche Signale und einen geregelten Weg für berechtigte Personen. Die konkrete Umsetzung muss mehrere Prozesse und Server berücksichtigen, damit parallele Anfragen nicht jeweils einen eigenen unverbrauchten Zähler erhalten.

Diese Entscheidungen gehören vor die aufwendige Passwortprüfung beziehungsweise in einen abgestimmten Ablauf mit ihr. Sonst kann ein Angreifer den gewählten Ressourcenaufwand selbst zur Überlastung ausnutzen. Fehlerereignisse dürfen intern unterscheidbar bleiben, damit der Betrieb Probleme erkennen kann. Nach außen sollten daraus aber keine zusätzlichen Auskünfte über vorhandene Konten entstehen. Eine automatisch veröffentlichte Meldung über den genauen Sperrgrund wäre deshalb gesondert zu bewerten. Das Beispiel enthält absichtlich keinen improvisierten Zähler in einer einzelnen PHP-Sitzung als angeblich vollständigen Schutz gegen solche Versuche.

Auch die Wiederherstellung verdient dieselbe Sorgfalt wie die Anmeldung. Ein gut gespeichertes Passwort hilft wenig, wenn ein leicht erratbarer Link die Änderung erlaubt. Wiederherstellungsnachweise benötigen einen begrenzten Zweck, geeignete Zufälligkeit, eine kurze passende Gültigkeit und eine kontrollierte einmalige Verwendung. Ob anschließend andere Sitzungen ungültig werden und welche Benachrichtigung sinnvoll ist, muss ausdrücklich entschieden werden. Eine Supportperson sollte nicht durch eine beiläufige telefonische Angabe ein fremdes Konto übernehmen können. Für wichtige Konten ist eine zusätzliche Bestätigung oder ein geeigneter zweiter Faktor besonders relevant. Der Artikel implementiert diese getrennten Prozesse nicht und behauptet folglich auch keine bestandene Prüfung ihrer Sicherheit.

Die Bedienbarkeit beeinflusst den Schutz ebenfalls. Ein Formular sollte Passwortmanager unterstützen, das Einfügen einer Passphrase erlauben und verständliche beschriftete Felder besitzen. Wer nach einem Ablauf unerwartet sämtliche Eingaben verliert, wiederholt möglicherweise sensible Angaben oder wählt bequemere Umgehungen. Eine erneute Anmeldung sollte deshalb den legitimen Arbeitsablauf berücksichtigen, ohne vertrauliche Formulardaten unkontrolliert in eine Adresse zu kopieren. Auch ein Rücksprungziel nach der Anmeldung ist zu begrenzen: Ein übergebener beliebiger Fremdlink darf nicht ungeprüft zum vertrauenswürdig wirkenden Weiterleitungsziel werden. Diese Entscheidungen sind Teil einer fachlichen Integration und kein Zusatznutzen eines besonders komplizierten Passwortfelds.

Schließlich muss der Betrieb wissen, was bei einem vermuteten Kontodiebstahl geschieht. Eine einzelne abgelaufene Sitzung reicht nicht aus, wenn weitere gültige Kennungen existieren. Dafür benötigt das System einen Überblick über aktive Sitzungen und eine kontrollierte Möglichkeit zum Widerruf. Die Wiederanmeldung nach einem solchen Ereignis darf nicht einfach an einen noch gültigen alten Nachweis anknüpfen. Ein dokumentierter Ablauf mit erreichbarer Verantwortung ist hierbei hilfreicher als eine lange Liste unverknüpfter Sicherheitsoptionen. Im kleinen Lernaufbau wird nur die konkrete aktuelle Sitzung stillgelegt. Die zusätzliche Kontenübersicht und ein kontoweiter Widerruf bleiben echte weitere Aufgaben.

• Den vorhandenen Identitätsdienst und seine Wartung vor einem Eigenbau bewerten.
• Passwortableitung, gespeicherte Parameter und unterstützte Laufzeit prüfen.
• Passphrasen erhalten und unzulässige Längen ausdrücklich ablehnen.
• Generische Fehler einschließlich Status und Verarbeitungsablauf betrachten.
• HTTPS, Cookieattribute und tatsächlichen Sitzungswechsel gemeinsam testen.
• Anmeldung, Abmeldung und weitere Zustandsänderungen gegen CSRF schützen.
• Inaktivität, absolute Laufzeit und serverseitigen Widerruf festlegen.
• Drosselung, Wiederherstellung und zusätzliche Faktoren passend ergänzen.
• Fachliche Berechtigungen bei jedem geschützten Zugriff prüfen.
• Protokolle auf notwendige Ereignisse begrenzen und Passwörter sowie Sitzungstoken aussparen.

Ein bestandenes Beispiel ist ein überprüfbarer Baustein für die technische Entscheidung. Zur belastbaren Anmeldung wird daraus ein abgestimmter Betrieb mit klaren Grenzen, überprüften Fachberechtigungen und einer verantworteten Wiederherstellung von Konten.