A07:2025 – Fehlerhafte Authentifizierung

Hintergrund.

Fehlerhafte Authentifizierung behält mit einer leichten Namensänderung seinen Rang #7 bei, um die 36 CWEs dieser Kategorie präziser widerzuspiegeln. Trotz der Vorteile standardisierter Frameworks hat diese Kategorie ihren Rang #7 aus 2021 gehalten. Zu den relevanten CWEs zählen CWE-259: Use of Hard-coded Password, CWE-297: Improper Validation of Certificate with Host Mismatch, CWE-287: Improper Authentication, CWE-384: Session Fixation sowie CWE-798: Use of Hard-coded Credentials.

Punktetabelle.

Zugeordnete CWEs	Max. Häufigkeit	Durchschn. Häufigkeit	Max. Abdeckung	Durchschn. Abdeckung	Durchschn. gewichtete Ausnutzbarkeit	Durchschn. gewichtete Auswirkung	Gesamtanzahl	Summe CVEs
36	15.80%	2.92%	100.00%	37.14%	7.69	4.44	1,120,673	7,147

Beschreibung.

Wenn ein:e Angreifer:in ein System dazu bringen kann, eine:n ungültige:n oder nicht autorisierte:n Nutzer:in als legitim anzuerkennen, liegt diese Schwachstelle vor. Schwachstellen bei der Authentifizierung können auftreten, falls die Anwendung:

automatisierte Angriffe wie Credential Stuffing ermöglicht, bei denen Angreifer:innen über eine Liste bekannter Benutzernamen und Passwörter verfügen. Jüngst wurde diese Angriffsmethode um hybride Passwort-Angriffe erweitert (auch als Password-Spray-Angriffe bekannt), bei denen Angreifer:innen Variationen kompromittierter Zugangsdaten verwenden, z. B. Password1!, Password2!, Password3! usw.
Brute-Force- oder andere automatisierte, skriptbasierte Angriffe ermöglicht, die nicht schnell genug unterbunden werden.
Standard-, schwache oder gängige Passwörter zulässt, wie z. B. „Password1" oder „admin/admin".
die Erstellung neuer Konten mit bereits als kompromittiert bekannten Zugangsdaten zulässt.
schwache oder ineffektive Verfahren zur Wiederherstellung von Zugangsdaten und Verfahren für vergessene Passwörter, wie z. B. „wissensbasierte Antworten", die nicht sicher gestaltet werden können.
Klartext-, verschlüsselte oder schwach gehashte Kennwortdatenspeicher (siehe A04:2025 – Fehlerhafter Einsatz von Kryptographie) verwendet.
fehlende oder unwirksame Multi-Faktor-Authentifizierung aufweist.
schwache oder ineffektive Ausweichmechanismen zulässt, falls keine Multi-Faktor-Authentifizierung verfügbar ist.
die Sitzungs-ID in der URL, einem versteckten Feld oder einer anderen unsicheren, für den Client zugänglichen Stelle offenlegt.
dieselbe Sitzungs-ID nach erfolgreichem Login wiederverwendet.
Benutzersitzungen oder Authentifizierungs-Tokens (hauptsächlich SSO-Tokens) beim Abmelden oder bei Inaktivität nicht korrekt invalidiert.
den Scope und die vorgesehene Audience der bereitgestellten Zugangsdaten nicht korrekt prüft.

Prävention und Gegenmaßnahmen.

Wenn möglich, sollte eine Multi-Faktor-Authentifizierung implementiert und deren Nutzung durchgesetzt werden, um automatisiertes Credential Stuffing, Brute-Force-Angriffe und die Wiederverwendung gestohlener Zugangsdaten zu verhindern.
Wenn möglich, die Nutzung von Passwort-Managern fördern und ermöglichen, um Nutzer:innen bessere Entscheidungen bei der Passwortwahl zu erleichtern.
Liefern Sie die Anwendung nicht mit Standard Login-Daten aus, insbesondere nicht für Admin-Konten.
Implementieren Sie Prüfungen auf schwache Passwörter, wie z. B. durch den Vergleich von neuen oder geänderten Passwörtern mit der Liste der 10.000 schlechtesten Passwörter.
Bei der Erstellung neuer Konten und Passwortänderungen Zugangsdaten gegen Listen bekannter kompromittierter Passwörter prüfen (z. B. mit haveibeenpwned.com).
Angleichung der Passwortlänge, -komplexität und -rotation an die Richtlinien des National Institute of Standards and Technology (NIST) 800-63b in Abschnitt 5.1.1 „Memorized Secrets" oder andere moderne, bewährte Passwortrichtlinien.
Passwortrotation nicht erzwingen, es sei denn, es besteht ein Verdacht auf eine Kompromittierung. Bei Verdacht sofortige Passwort-Resets durchsetzen.
Sicherstellen, dass die Registrierung, die Wiederherstellung von Zugangsdaten und die API-Pfade gegen Angriffe zur Ermittlung von Konten gehärtet sind, indem für alle Resultate die gleiche Nachricht ausgegeben wird („Ungültiger Benutzername oder Passwort.”).
Begrenzen oder bremsen Sie fehlgeschlagene Anmeldeversuche immer weiter aus, aber achten Sie darauf, dass hierbei kein Denial-of-Service-Szenario entsteht. Loggen Sie alle Fehlversuche und alarmieren Sie die Administrator:innen, wenn Credential Stuffing, Brute Force oder andere Angriffe erkannt oder vermutet werden.
Verwenden Sie einen serverseitigen, sicheren, integrierten Sitzungsmanager, der für jede Sitzung eine neue zufällige Sitzungs-ID mit hoher Entropie erzeugt. Die Sitzungs-ID sollte nicht in der URL enthalten sein, sicher in einem sicheren Cookie gespeichert und nach Abmeldung, Inaktivität und absoluten Timeouts invalidiert werden.
Idealerweise ein bewährtes, vertrauenswürdiges System für Authentifizierung, Identitätsverwaltung und Session-Management verwenden. Dieses Risiko wann immer möglich durch den Einsatz eines gehärteten und gut getesteten Systems auslagern.
Die vorgesehene Verwendung bereitgestellter Zugangsdaten prüfen, z. B. bei JWTs die aud- und iss-Claims sowie Scopes validieren.

Beispielhafte Angriffsszenarien.

Szenario Nr. 1: Credential Stuffing, die Verwendung von Listen bekannter Benutzernamen- und Passwortkombinationen, ist heute ein sehr verbreiteter Angriff. Jüngst wurde beobachtet, dass Angreifer:innen Passwörter basierend auf typischem menschlichem Verhalten „inkrementieren" oder abwandeln, z. B. von „Winter2025" zu „Winter2026" oder von „ILoveMyDog6" zu „ILoveMyDog7". Diese Methode wird als hybrider Credential-Stuffing-Angriff oder Password-Spray-Angriff bezeichnet und kann noch effektiver sein als die klassische Variante. Verfügt eine Anwendung über keine Abwehrmechanismen gegen automatisierte Angriffe oder Credential Stuffing, kann sie als Passwort-Orakel genutzt werden, um gültige Zugangsdaten zu ermitteln und unbefugten Zugriff zu erlangen.

Szenario Nr. 2: Die meisten erfolgreichen Authentifizierungsangriffe erfolgen aufgrund der andauernden Verwendung von Passwörtern als einzigem Authentifizierungsfaktor. Die früher als Best Practices geltenden Anforderungen an Passwortwechsel und -komplexität verleiten Nutzer:innen sowohl zur Wiederverwendung als auch zur Wahl schwacher Passwörter. Organisationen wird empfohlen, diese Praktiken gemäß NIST 800-63 einzustellen und die Nutzung von Multi-Faktor-Authentisierung auf allen wichtigen Systemen durchzusetzen.

Szenario Nr. 3: Die Session-Timeouts von Anwendungen sind nicht korrekt implementiert. Eine Nutzer:in verwendet einen öffentlichen Computer und schließt die Browser-Registerkarte, anstatt sich abzumelden. Ein weiteres Beispiel: Eine SSO-Sitzung kann nicht per Single Logout (SLO) geschlossen werden – ein einzelner Login gewährt Zugang zu mehreren Systemen (z. B. E-Mail, Dokumente, Chat), aber der Logout erfolgt nur im aktuellen System. Greifen Angreifer:innen danach auf denselben Browser zu, haben sie Zugriff auf alle noch aktiven Sitzungen. Dasselbe Problem kann in Büros auftreten, wenn eine sensible Anwendung nicht ordnungsgemäß beendet wurde und Kolleg:innen vorübergehend Zugriff auf den entsperrten Computer haben.