Was ist Broken Authentication? Ursachen, Auswirkungen & Prävention

Broken Authentication ermöglicht Angreifern, Login-Kontrollen zu umgehen, Sitzungen zu kapern und Tokens zu fälschen. Erfahren Sie, wie es funktioniert, wen es betrifft und wie Sie es verhindern können.

Was ist Broken Authentication?

Broken Authentication ist eine Schwachstellenklasse, die es Angreifern ermöglicht, Benutzeridentitäten zu kompromittieren, indem sie Schwächen in der Art und Weise ausnutzen, wie Anwendungen Identitäten verifizieren und diesen verifizierten Zustand aufrechterhalten. Wenn Anmeldeverfahren, Sitzungsverwaltung oder Prozesse zur Wiederherstellung von Zugangsdaten fehlerhaft sind, können Angreifer legitime Benutzer imitieren, Privilegien eskalieren und Systeme ohne Autorisierung betreten.

Diese Schwachstelle ist seit den ersten Ausgaben in jeder OWASP-Liste vertreten. OWASP hat die Kategorie im Laufe der Zeit umbenannt und verfeinert, um eine breitere Abdeckung von Authentifizierungs-Schwächen widerzuspiegeln – nicht etwa, weil sie an Bedeutung verloren hätte.

Der Umfang von Broken Authentication geht weit über einfaches Passwort-Raten hinaus. Er umfasst Credential Stuffing, Session Fixation, MFA-Umgehung, Token-Fälschung, fest codierte Zugangsdaten und fehlende Authentifizierung bei kritischen Funktionen. Die zugrundeliegende CWE für die gesamte Kategorie ist CWE-287, wobei in neueren OWASP-Klassifikationen eine breite Palette verwandter CWEs zugeordnet ist.

Laut dem DBIR-Bericht bleibt der Missbrauch von Zugangsdaten eine der führenden Methoden für den Erstzugriff bei Sicherheitsvorfällen. Wer versteht, wie Broken Authentication funktioniert, kann sie effektiver verhindern.

Wie funktioniert Broken Authentication?

Broken Authentication nutzt Schwächen in zwei unterschiedlichen Fehlerdomänen aus: Authentifizierung, die regelt, wie Anwendungen Identitäten verifizieren, und Sitzungsverwaltung, die bestimmt, wie diese verifizierte Identität während des Besuchs aufrechterhalten wird. Jede Domäne bietet unterschiedliche Angriffsflächen, führt aber zum gleichen Ergebnis: unautorisierter Zugriff.

Fehler bei der Authentifizierung

Wenn eine Anwendung die Benutzeridentität nicht korrekt prüft, verschaffen sich Angreifer Zugang durch die Vordertür. Ein Credential Stuffing-Angriff sendet gestohlene Kombinationen aus Benutzernamen und Passwort an Ihren Login-Endpunkt. Fehlen Ihrer Anwendung Ratenbegrenzung oder Kontosperrung, kann der Angreifer Zugangsdaten in großem Maßstab testen, bis gültige Kombinationen gefunden werden.

Der Angriffsablauf ist einfach: Der Angreifer beschafft sich Zugangsdaten aus früheren Vorfällen. Diese Paare werden automatisiert gegen Ihre Login-Seite getestet. Die Anwendung akzeptiert jeden Versuch ohne Drosselung, Sperre oder CAPTCHA. Bei einem Treffer erhält der Angreifer vollen Kontozugriff.

Brute Force folgt einem ähnlichen Muster, generiert aber Passwort-Kombinationen statt bekannte Zugangsdaten zu wiederholen. Password Spraying geht umgekehrt vor: Ein häufiges Passwort wird gleichzeitig gegen viele Konten getestet, um Kontosperrgrenzen zu umgehen.

Fehler bei der Sitzungsverwaltung

Auch nach erfolgreicher Authentifizierung können Fehler im Sitzungsmanagement den authentifizierten Zustand an einen Angreifer übergeben. Bei einem Session Fixation-Angriff (CWE-384) setzt der Angreifer eine bekannte Sitzungs-ID vor dem Login. Wenn Ihre Anwendung die Sitzungs-ID nach erfolgreicher Authentifizierung nicht neu generiert, kann der Angreifer die vordefinierte ID nutzen, um auf Ihre authentifizierte Sitzung zuzugreifen.

Die Offenlegung von Sitzungstoken schafft einen weiteren Angriffsweg. Wenn Sitzungs-IDs in URLs erscheinen, werden sie in Server-Logs, Browserverlauf und HTTP-Referrer-Headern protokolliert. Ein Angreifer, der die URL erhält, erhält auch die Sitzung. Unzureichende Sitzungsablaufsteuerung (CWE-613) verschärft das Problem: Wenn Sie einen Browser-Tab schließen, ohne sich abzumelden, kann ein späterer Nutzer im selben Browser Ihre Sitzung weiterhin nutzen.

MFA-Umgehung

Multi-Faktor-Authentifizierung fügt eine zweite Verifizierungsebene hinzu, aber Angreifer haben zuverlässige Umgehungstechniken entwickelt. MFA Fatigue, auch Prompt Bombing genannt, überschwemmt das Gerät eines Benutzers mit Push-Benachrichtigungen, bis dieser eine genehmigt, um die Unterbrechungen zu beenden. Der Uber-Vorfall wird oft als Beispiel genannt, wie gestohlene Zugangsdaten, wiederholte MFA-Aufforderungen und Social Engineering kombiniert werden können, um Zugang zu internen Systemen zu erhalten.

Diese Mechanismen funktionieren, weil Broken Authentication selten nur ein einzelner Fehler ist. Es ist eine Kette von Schwächen – von schwachen Zugangsdaten über fehlende Ratenbegrenzung bis zu schlechter Sitzungsverwaltung –, die Angreifer nacheinander ausnutzen.

Arten von Broken Authentication

Broken Authentication ist keine einzelne Schwachstelle, sondern eine Kategorie, die sechs verschiedene Fehlertypen umfasst. Jeder zielt auf eine andere Schicht des Authentifizierungs-Stacks und erfordert unterschiedliche Gegenmaßnahmen.

Typ	Was versagt	Gängige Angriffsmethoden	Kern-CWEs
Angriffe auf Zugangsdaten	Passwortrichtlinie, Ratenbegrenzung	Credential Stuffing, Brute Force, Password Spraying	CWE-307, CWE-521
Fehler in der Sitzungsverwaltung	Sitzungs-ID-Lebenszyklus und -Speicherung	Session Fixation, Session Hijacking, Cookie-Diebstahl	CWE-384, CWE-613
MFA-Umgehung	Implementierung des zweiten Faktors	MFA Fatigue, TOTP-Relay, SIM-Swapping	CWE-308
Token-Fälschung	Schutz kryptografischer Schlüssel	SAML Assertion Forgery, JWT-Manipulation, OAuth-Token-Diebstahl	CWE-347, CWE-345
Fest codierte Zugangsdaten	Zugangsdatenverwaltung im Code	Statisches Auslesen von Zugangsdaten aus Quell- oder Konfigurationsdateien	CWE-798
Fehlende Authentifizierung	Durchsetzung der Authentifizierung bei kritischen Funktionen	Direkter Objektzugriff, Umgehung von API-Endpunkten, alternativer Pfadzugriff	CWE-306, CWE-288

Zu wissen, welcher Typ in einer Anwendung vorliegt, bestimmt, welche Gegenmaßnahmen greifen und welche forensischen Hinweise zu suchen sind. Credential Stuffing erfordert Ratenbegrenzung und MFA; fehlende Authentifizierung bei einer Admin-API verlangt eine grundlegend andere Reaktion.

Ursachen von Broken Authentication

Broken Authentication entsteht nicht durch einen einzelnen Designfehler. Sie resultiert aus sich verstärkenden Schwächen in vier Kategorien, die laut OWASP-Empfehlung mit anderen Top-10-Risiken wie fehlerhafter Zugriffskontrolle, kryptografischen Fehlern und veralteten Bibliotheken verbunden sind.

Fehler in der Passwortrichtlinie

Das Zulassen von schwachen, Standard- oder allgemein bekannten Passwörtern bleibt die grundlegendste Ursache. Wenn Ihre Anwendung gängige Standardpasswörter ohne Durchsetzung akzeptiert, bieten Sie Angreifern einen einfachen Einstiegspunkt (CWE-521). NIST 63B-4 verlangt, dass neue Passwörter gegen Listen bekannter kompromittierter Passwörter geprüft werden – viele Anwendungen überspringen diesen Schritt jedoch weiterhin.

Passwort-Wiederverwendung verschärft das Problem. Der DBIR-Bericht hebt hervor, dass Passwort-Wiederverwendung über Dienste hinweg weiterhin verbreitet ist, was gestohlene Zugangsdaten für Angreifer deutlich wertvoller macht.

Fehler im Authentifizierungsablauf

Fehlende MFA (CWE-308) lässt Konten durch einen einzigen, leicht zu stehlenden, zu erratenden oder zu phishenden Faktor schützen. Schwache Mechanismen zur Wiederherstellung von Zugangsdaten, die auf wissensbasierten Antworten beruhen, schaffen einen parallel leicht zu erratenden Authentifizierungspfad. Das Fehlen von Ratenbegrenzung bei Login-Versuchen (CWE-307) ermöglicht es Angreifern, große Mengen an Kombinationen ohne Konsequenzen zu testen.

Fest codierte Zugangsdaten im Quellcode oder in Konfigurationsdateien (CWE-798) stellen einen vollständigen Designfehler dar. Diese Schwachstelle erscheint in aktuellen CWE-Top-25-Rankings und wurde durch eine CISA-Warnung bei aktiven Angriffen auf industrielle Steuerungssysteme bestätigt.

Fehler im Sitzungslebenszyklus

Drei Fehler im Sitzungslebenszyklus schaffen direkte Angriffswege:

• Keine Neugenerierung der Sitzungs-ID nach Login ermöglicht Session Fixation-Angriffe
• Sitzungen ohne Inaktivitäts- oder absolute Zeitlimits verlängern das Zeitfenster für Session Hijacking
• Einbettung von Sitzungstoken in URLs statt in sicheren Cookies führt zur Weitergabe von Zugangsdaten über alle Systeme, die die URL protokollieren oder zwischenspeichern

Jeder dieser Fehler erhöht das Risiko unabhängig; zusammen bieten sie Angreifern mehrere Möglichkeiten, unautorisierten Zugriff aufrechtzuerhalten.

Kryptografische und Transportfehler

Die Speicherung von Passwörtern im Klartext, die Verwendung reversibler Verschlüsselung oder schwacher Hashing-Algorithmen bedeutet, dass bei einem Datenbankvorfall Zugangsdaten direkt offengelegt werden. Transportfehler wie fehlerhafte Zertifikatsvalidierung (CWE-295) ermöglichen es Angreifern, Authentifizierungsverkehr abzufangen. Diese Ursachen überschneiden sich häufig mit OWASP A02:2021 Cryptographic Failures und zeigen, wie Broken Authentication mit anderen Schwachstellenkategorien zusammenhängt.

Diese vier Kategorien treten selten isoliert auf. Eine schwache Passwortrichtlinie macht Credential Stuffing möglich; fehlende Ratenbegrenzung macht es praktikabel; schlechte Sitzungsverwaltung verlängert das Angriffsfenster nach erfolgreichem Zugriff. Zu wissen, welche Ursachen im eigenen System vorliegen, bestimmt sowohl das Risiko als auch den Ansatz zur Behebung.

Auswirkungen und Risiken von Broken Authentication

Die Folgen von Broken Authentication reichen von der Kompromittierung einzelner Konten bis zu unternehmensweiten Vorfällen mit regulatorischen, finanziellen und betrieblichen Auswirkungen.

Häufigkeit von Sicherheitsvorfällen

Fehler bei der Authentifizierung gehören zu den am häufigsten ausgenutzten Erstzugriffswegen. Der DBIR-Bericht bestätigt, dass der Missbrauch von Zugangsdaten weiterhin ein Haupttreiber für Sicherheitsvorfälle ist. Bei grundlegenden Webanwendungsangriffen sind gestohlene Zugangsdaten insbesondere im Finanzsektor besonders auffällig.

Finanzielle Folgen

Der IBM-Bericht ergab, dass die durchschnittlichen globalen Kosten einer Datenpanne im Jahr 2024 auf 4,88 Millionen US-Dollar gestiegen sind, ein Anstieg um 10 % gegenüber dem Vorjahr. Finanzdienstleister verzeichneten durchschnittlich 6,08 Millionen US-Dollar pro Vorfall, 22 % über dem globalen Wert. Über die direkten Kosten hinaus berichteten 70 % der betroffenen Organisationen von erheblichen oder moderaten betrieblichen Störungen.

Kaskadierende Geschäftsauswirkungen

Broken Authentication bleibt selten auf einen Bereich beschränkt. Ein kompromittiertes Zugangsdatenpaar wird zum Ausgangspunkt für laterale Bewegung, Privilegieneskalation, Datenexfiltration und Ransomware-Einsatz. Der Verizon DBIR fand eine Korrelation zwischen Ransomware-Opfern und dem Auftauchen von Opfer-Domains in Credential Dumps, was Authentifizierungsschwächen direkt mit Ransomware-Risiken verknüpft.

Broken Authentication ist kein abstraktes Anwendungssicherheitsproblem. Es ist ein primärer Mechanismus, über den Sicherheitsvorfälle beginnen.

Wie Angreifer Broken Authentication ausnutzen

Angreifer wählen ihre Methode basierend auf der spezifischen Authentifizierungsschwäche, die sie entdecken. Hier sind die wichtigsten Ausnutzungstechniken, zugeordnet zu den jeweiligen CWEs.

MFA Fatigue und Social Engineering

Wenn MFA einen Credential Stuffing-Versuch blockiert, eskalieren Angreifer zu Social Engineering. MFA Fatigue sendet wiederholt Push-Benachrichtigungen an den legitimen Benutzer, bis dieser eine genehmigt. Die CISA-Warnung dokumentierte eine verwandte Technik: Nach dem Brute-Forcing eines schwachen Passworts bei einem inaktiven Konto registrierten die Angreifer ein neues MFA-Gerät, da die Standardkonfiguration von Duo die Neuregistrierung für inaktive Konten erlaubte und so Netzwerkzugriff ermöglichte.

SAML-Token-Fälschung

In der SolarWinds/SUNBURST-Kampagne extrahierten Angreifer private Verschlüsselungsschlüssel aus Active Directory Federation Services-Containern und fälschten dann SAML-Assertions, die für jede vertrauende Partei gültig erschienen. Laut CISA-Warnung umging diese Golden SAML-Technik die Authentifizierung vollständig, ohne legitime Zugangsdaten zu besitzen, und ermöglichte Zugriff auf Cloud-Umgebungen mehrerer US-Bundesbehörden.

Sitzungshijacking durch Token-Offenlegung

CVE-2023-4966, bekannt als Citrix Bleed, ermöglichte es Angreifern, gültige Sitzungstoken aus Remote-Access-Appliances zu extrahieren. Mit einem gestohlenen Sitzungstoken kann der Angreifer einen bereits authentifizierten Benutzer imitieren und sowohl Passwort- als auch MFA-Schutz vollständig umgehen. CISA bestätigte aktive Zero-Day-Ausnutzung vor Verfügbarkeit eines Patches [cite-19].

Authentifizierungsumgehung über alternativen Pfad

Manche Schwachstellen heben Authentifizierungsanforderungen vollständig auf. Eine Schwachstelle in einem Netzwerkgerät ermöglichte nicht authentifizierten Super-Admin-Zugriff über eine Node.js-Websocket-Verbindung und erhielt eine kritische Bewertung [cite-20]. Eine weitere Schwachstelle in einer Verwaltungsoberfläche erlaubte nicht authentifizierte Privilegieneskalation über das Webinterface. Das Management-Interface-Problem entspricht CWE-306: vollständiges Fehlen von Authentifizierung bei einer kritischen Funktion, während das Websocket-Problem zu CWE-288 gehört: Authentifizierungsumgehung über alternativen Pfad oder Kanal.

Capture-Replay-Angriffe

Angreifer fangen Authentifizierungstoken oder Zugangsdaten während der Übertragung ab und spielen sie erneut ein, um Zugriff zu erhalten (CWE-294). Ohne sendergebundene Token gemäß RFC 9700 bleiben OAuth-Implementierungen für diese Technik anfällig.

Jede dieser Techniken hinterlässt unterschiedliche forensische Spuren, was die Erkennung und Reaktion bestimmt.

Wer ist von Broken Authentication betroffen?

Broken Authentication betrifft jede Organisation, die Benutzeridentitäten zur Zugriffskontrolle nutzt. Bestimmte Sektoren und Systemtypen tragen jedoch ein erhöhtes Risiko.

Webanwendungen und APIs

Jede Anwendung, die ihre eigene Authentifizierung verwaltet, ist direkt exponiert. OWASP behandelt API-spezifische Broken Authentication explizit im OWASP API Security-Projekt und weist darauf hin, dass Authentifizierungsendpunkte strengere Brute-Force-Schutzmaßnahmen als reguläre API-Ratenbegrenzungen benötigen.

Cloud- und SaaS-Plattformen

Die Snowflake/UNC5537-Kampagne zeigte, dass Cloud-Plattformen mit Ein-Faktor-Authentifizierung besonders attraktive Ziele sind und viele Organisationen kompromittiert wurden, weil betroffene Konten keine MFA hatten. Cloud-Plattformen, die die Authentifizierung an Identitätsanbieter delegieren, übernehmen deren Schwächen.

Finanzdienstleister

Finanzinstitute tragen ein überproportionales Risiko. Die Verizon Finance Snapshot zeigte, dass gestohlene Zugangsdaten bei Webanwendungsangriffen im Finanzsektor dominieren. Der Credential Stuffing-Vorfall bei PayPal führte zu einer regulatorischen Einigung und verpflichtender MFA für US-Kundenkonten.

Kritische Infrastruktur und Netzwerkgeräte

VPN-Gateways, Firewalls und Netzwerkmanagement-Interfaces sind bevorzugte Ziele. CVE-2019-11510, CVE-2024-55591 und CVE-2024-53704 stehen für Authentifizierungsumgehungen in Perimeter-Geräten, die CISA in ihren Katalog bekannter ausgenutzter Schwachstellen aufgenommen hat.

Gesundheitswesen und Behörden

Organisationen, die sensible personenbezogene Daten verarbeiten, sind sowohl von Sicherheitsvorfällen als auch von regulatorischen Konsequenzen betroffen. CISA dokumentiert, dass schwache Authentifizierung zu den häufigsten Feststellungen bei der CISA-Authentifizierungsbewertung für Federal High Value Asset-Systeme zählt.

Die folgenden Vorfälle zeigen, wie sich diese Risiken in verschiedenen Branchen materialisieren.

Praxisbeispiele für Broken Authentication

Diese Vorfälle zeigen, wie Broken Authentication in unterschiedlichen Branchen, Angriffstechniken und Auswirkungsdimensionen auftritt.

23andMe: Credential Stuffing führt zu massiver Datenexponierung

Angreifer nutzten Credential Stuffing, um auf einen kleinen Teil von 23andMe-Benutzerkonten zuzugreifen, bei denen Passwörter mit denen aus früheren Vorfällen übereinstimmten. Über die DNA Relatives-Funktion weitete sich dieser Zugang auf einen viel größeren Satz exponierter Profildaten aus. Laut 23andMe SEC-Filings entstanden dem Unternehmen Vorfallskosten. MFA war zum Zeitpunkt des Vorfalls nicht verpflichtend.

Snowflake/UNC5537: Infostealer-Zugangsdaten später genutzt

Der Bedrohungsakteur UNC5537 nutzte Credential Theft durch Infostealer-Malware, um Organisationen über Snowflake-Cloud-Data-Warehouse-Konten zu kompromittieren. Laut Mandiant-Untersuchung war bei keinem der betroffenen Konten MFA aktiviert. Zu den Opfern zählten Ticketmaster, Santander Bank und Advance Auto Parts.

SolarWinds/SUNBURST: SAML-Token-Fälschung

Russische staatliche Akteure kompromittierten den SolarWinds-Build-Prozess und nutzten den Zugang, um ADFS-Private-Keys zu stehlen. Laut CISA-Bericht fälschten sie vertrauenswürdige SAML-Authentifizierungstoken, um ohne legitime Zugangsdaten auf Cloud-Umgebungen mehrerer US-Regierungsbehörden zuzugreifen.

PayPal: Credential Stuffing mit regulatorischen Folgen

Angreifer nutzten Credential Stuffing, um auf Kundenkonten zuzugreifen und hochsensible Kundendaten offenzulegen. Die New Yorker DFS verhängte eine regulatorische Einigung und verpflichtete MFA für US-Kundenkonten.

GoDaddy: Mehrjährige Kompromittierung von Zugangsdaten

Ein kompromittiertes Administrationspasswort ermöglichte Angreifern Zugriff auf die Managed WordPress-Umgebung von GoDaddy, laut GoDaddy-Bericht. Der Vorfall betraf zahlreiche aktuelle und inaktive Managed WordPress-Kunden, mit gestohlenen WordPress-Admin-Zugangsdaten, FTP-Konten und E-Mail-Adressen. Angreifer installierten zudem Malware und erlangten Quellcode.

Yahoo: Cookie-Fälschung im großen Stil

Der Yahoo-Vorfall betraf letztlich alle 3 Milliarden Benutzerkonten, laut New York Times. Angreifer nutzten gefälschte Authentifizierungs-Cookies, um ohne Passwörter auf Konten zuzugreifen. Ein späterer Vorfall beinhaltete Spear-Phishing auf Administrationszugangsdaten, wobei die Cookie-Fälschung mit einem staatlich unterstützten Akteur in Verbindung gebracht wurde.

Diese Vorfälle sind Teil eines größeren historischen Musters, das sich über zwei Jahrzehnte erstreckt.

Broken Authentication: Eine Zeitleiste

Die Geschichte von Broken Authentication spiegelt die Entwicklung der Websicherheit wider – von frühen Fehlern im Sitzungsmanagement bis zu heutigen Angriffen auf die Identitätsschicht.

Jahr	Meilenstein
2004	Erste OWASP Top 10 veröffentlicht; „Broken Authentication and Session Management“ auf Platz A3.
2012	LinkedIn-Vorfall legt große Zugangsdatenmenge durch unsalting SHA-1-Hashing offen.
2013	Yahoo-Vorfall betrifft alle Benutzerkonten; Schadcode umgeht Kontrollen. OWASP stuft Broken Authentication auf A2 ein.
2017	OWASP Top 10 belässt Broken Authentication auf A2 und hebt die Verfügbarkeit großer Credential-Sammlungen für Stuffing hervor.
2019	CVE-2019-11510, Pulse Connect Secure, wird in CISA KEV aufgenommen.
2020	SolarWinds/SUNBURST: SAML-Token-Fälschung kompromittiert US-Bundesbehörden.
2021	CISA dokumentiert russische Akteure, die Duo MFA durch Neuregistrierung inaktiver Konten umgehen. OWASP stuft die Kategorie als A07 ein.
2022	Uber durch MFA Fatigue kompromittiert. PayPal Credential Stuffing führt zu regulatorischer Einigung.
2023	23andMe Credential Stuffing legt Millionen Profile offen. Citrix Bleed ermöglicht Session Hijacking.
2024	Snowflake/UNC5537-Kampagne kompromittiert zahlreiche Organisationen ohne MFA.
2025	OWASP Top 10:2025 erweitert die Kategorie weiter. CVE-2024-55591 erhält kritische Aufmerksamkeit, und der Verizon DBIR bestätigt Credential Abuse als führenden Erstzugriffsweg.

Broken Authentication hat sich von einer Webanwendungsschwachstelle zu einem Identitätssicherheitsproblem über Anwendungen, Infrastruktur und Cloud-Umgebungen hinweg entwickelt.

Wie erkennt man Broken Authentication?

Die Erkennung von Broken Authentication erfordert einen mehrschichtigen Ansatz, der Designfehler, Missbrauch von Zugangsdaten zur Laufzeit und Verhaltensanomalien nach der Authentifizierung abdeckt.

Log- und Sitzungsanalyse

Das OWASP Authentication Cheat Sheet schreibt vor, dass alle Authentifizierungsfehler, Passwortfehler und Kontosperrungen protokolliert und überprüft werden müssen. Suchen Sie nach Mustern, die auf Credential Stuffing hindeuten: hohe Fehlanmelderaten bei verschiedenen Konten aus demselben IP-Bereich oder Fehlanmeldungen bei einem Konto aus unterschiedlichen geografischen Regionen.

Das OWASP Session Management Cheat Sheet benennt Sitzungsereignisse, die eine erneute Authentifizierung auslösen sollten: Logins von neuen oder verdächtigen IP-Adressen, versuchte Passwortänderungen und abgeschlossene Kontowiederherstellungen. Unterscheiden Sie zwischen permissivem Sitzungsmanagement, das beliebige benutzerdefinierte Sitzungs-IDs akzeptiert und angreifbar ist, und strengem Sitzungsmanagement, das nur servergenerierte IDs zulässt.

Dynamische Anwendungssicherheitstests (DAST)

Der OWASP Testing Guide definiert authentifizierungsspezifische Testverfahren in der WSTG-ATHN-Serie. Diese umfassen Tests auf Standardzugangsdaten, schwache Sperrmechanismen, Umgehung des Authentifizierungsschemas, anfällige Passwort-Reset-Flows, schwache Sicherheitsfragen und Fehler bei der MFA-Implementierung. Tools wie DAST-Scanner und Passwort-Testprogramme führen diese Tests gegen laufende Anwendungen aus.

Statische Analyse auf fest codierte Zugangsdaten

Statische Anwendungssicherheitstests (SAST) durchsuchen Quellcode vor der Bereitstellung nach fest codierten Passwörtern (CWE-798), schwachen kryptografischen Implementierungen und unsicherer Sitzungslogik. So werden Schwächen im Credential Management erkannt, die DAST nicht erfassen kann, weil sie in nicht extern erreichbaren Codepfaden liegen.

Identity Threat Identification and Response (ITDR)

Angreifer mit gültigen gestohlenen Zugangsdaten umgehen sowohl Netzwerk- als auch Endpoint Security, da ihr Datenverkehr legitim erscheint und keine Malware enthält. ITDR-Systeme überwachen gezielt die Identitätsschicht und vergleichen Authentifizierungsereignisse mit Verhaltensbaselines. Auffällige Abweichungen sind Logins aus ungewöhnlichen Regionen, laterale Bewegungen über nicht zusammenhängende Datensätze und ungewöhnliche Privilegieneskalationen. XDR-Architektur erweitert dies, indem Authentifizierungsanomalien mit anschließender lateraler Netzwerkbewegung korreliert werden, sodass die gesamte Angriffskette sichtbar wird, die isolierte Tools übersehen.

Wie verhindert man Broken Authentication?

Die Prävention richtet sich direkt nach den Ursachen. Jede der folgenden Maßnahmen adressiert spezifische Broken Authentication-Subtypen mit Verweisen auf relevante Standards.

Phishing-resistente MFA einsetzen

CISA-Empfehlung nennt FIDO2/WebAuthn und PIV/CAC-Smartcards als Goldstandard für phishing-resistente MFA. Push-basierte MFA ist anfällig für Fatigue-Angriffe und Echtzeit-Phishing, das Einmalcodes abfragt. NIST SP 800-63B verlangt zugelassene MFA auf höheren Vertrauensniveaus.

Moderne Passwortrichtlinien durchsetzen

Richten Sie sich nach den Anforderungen von NIST 63B-4: Prüfen Sie neue Passwörter gegen Listen bekannter kompromittierter Passwörter, erlauben Sie alle Zeichentypen einschließlich Unicode und Leerzeichen, setzen Sie eine Mindestlänge durch und verlangen Sie keine regelmäßige Rotation. Das OWASP Authentication Cheat Sheet empfiehlt einen Passwortstärkemesser und eine Rotation nur bei bestätigtem Leak.

Für die Speicherung empfiehlt das Password Storage Cheat Sheet Argon2id als primären Hash-Algorithmus, mit scrypt, bcrypt und PBKDF2 als akzeptable Alternativen. Verwenden Sie korrektes Salting, Peppering und Work-Factor-Konfiguration mit Upgrade-Pfaden für Legacy-Hashes.

Ratenbegrenzung und Kontosperrung implementieren

Setzen Sie Brute-Force-Schutzmaßnahmen an Authentifizierungsendpunkten um, die strenger sind als die Standard-API-Ratenbegrenzung. Das OWASP API Security 2023-Projekt fordert Kontosperrung, CAPTCHA und progressive Verzögerungen. Der OWASP Testing Guide beschreibt typische Sperrschwellen in der Praxis.

Nach erfolgreicher Authentifizierung wird die Sitzung selbst zur neuen Angriffsfläche. Die Absicherung der Ausstellung, Speicherung und des Ablaufs der Sitzung ist eine eigenständige und ebenso wichtige Maßnahme.

Sichere Sitzungsverwaltung

Verwenden Sie servergenerierte Sitzungs-IDs mit hoher Entropie aus einem kryptografisch sicheren Zufallszahlengenerator. Generieren Sie Sitzungs-IDs nach jedem erfolgreichen Login neu. Setzen Sie Inaktivitäts- und absolute Zeitlimits. Betten Sie Sitzungstoken niemals in URLs ein. Das OWASP Session Management Cheat Sheet empfiehlt die Nutzung von Frameworks wie J2EE, ASP.NET, PHP statt Eigenentwicklungen.

Absicherung von Kontenabfrage und -wiederherstellung

Verwenden Sie identische Antwortmeldungen für alle Authentifizierungsergebnisse, damit Angreifer nicht zwischen gültigen und ungültigen Benutzernamen unterscheiden können. Das Forgot Password Cheat Sheet schreibt vor, dass Sicherheitsfragen nicht als alleiniger Wiederherstellungsmechanismus dienen dürfen und dass Credential-Recovery-Endpunkte denselben Brute-Force-Schutz wie Login-Endpunkte benötigen.

Standardzugangsdaten eliminieren

OWASP A07 sagt klar: „Keine Standardzugangsdaten ausliefern oder bereitstellen, insbesondere nicht für Admin-Benutzer.“ Fügen Sie Prüfungen auf Standardzugangsdaten in Ihre Deployment-Checkliste ein.

Für Anwendungen mit OAuth und OIDC reichen starke Zugangsdaten und Sitzungs-Hygiene allein nicht aus. Token-basierte Kontrollen verhindern Replay- und Fälschungsangriffe oberhalb der Zugangsdatenebene.

Token-Sicherheit für OAuth/OIDC durchsetzen

RFC 9700 verlangt sendergebundene Zugriffstoken, Rotation von Refresh Tokens für Public Clients und Mutual TLS gemäß RFC 8705, um Token-Replay-Angriffe zu verhindern.

Die Umsetzung dieser Maßnahmen erfordert die richtigen Tools über mehrere Sicherheitsschichten hinweg.

Tools zur Erkennung und Prävention

Die Verhinderung von Broken Authentication erfordert Abdeckung durch mehrere Tool-Kategorien, da keine einzelne Kategorie die gesamte Angriffsfläche abdeckt.

Tool-Kategorie	Hauptfunktion	Adressierte Authentifizierungsangriffe
DAST-Tools	Testen von Authentifizierungsabläufen zur Laufzeit	Umgehung, schwache Sperre, Session-Token-Offenlegung, Standardzugangsdaten
SAST-Tools	Quellcodeanalyse vor Bereitstellung	Fest codierte Zugangsdaten, schwache Kryptografie, unsichere Sitzungslogik
ITDR	Verhaltensüberwachung auf Identitätsebene	Credential Stuffing, laterale Bewegung nach Kompromittierung, Privilegieneskalation
XDR mit Identitätskorrelation	Schichtübergreifende Telemetrie: Endpoint, Netzwerk, Cloud, Identität	Laterale Bewegung nach Authentifizierung, unmögliche Reisen, vollständige Angriffskettenrekonstruktion
Behavioral AI / UEBA	Statistische Anomalieerkennung in Authentifizierungsereignissen	Missbrauch von Zugangsdaten, anomale Servicekontenaktivität

Kein einzelnes Tool deckt die gesamte Angriffsfläche allein ab. Effektive Abdeckung kombiniert Tests vor der Bereitstellung, Verhaltensüberwachung zur Laufzeit und Identitätskorrelation über alle Quellen hinweg. Im Folgenden wird beschrieben, wie SentinelOne diesen Stack ganzheitlich adressiert.

Wie kann SentinelOne helfen?

Wenn Angreifer Zugangsdaten stehlen, handeln sie schnell. SentinelOne hilft Ihnen, identitätsbasierte Angriffe in Ihrer gesamten Umgebung in Echtzeit zu erkennen und zu stoppen. So arbeiten unsere Lösungen zusammen und unterstützen Sie.

Singularity™ AI SIEM: Umfassende Bedrohungstransparenz

Starten Sie mit Singularity™ AI SIEM. Es sammelt Authentifizierungs-Telemetrie von Endpunkten, Netzwerken, Cloud-Diensten und Identitätsanbietern und korreliert alles zentral. Die Verhaltensanalyse erkennt unmögliche Reisebewegungen (dasselbe Token in New York und Tokio im Minutenabstand), gleichzeitige Sitzungsanomalien und Privilegieneskalation durch Token-Manipulation. In den MITRE ATT&CK Evaluierungen 2024 erkannte die Singularity-Plattform 100 % der Angriffsschritte ohne Verzögerung und mit 88 % weniger Alerts als der Median – Ihr Team wird also nicht von Alarmen überflutet.

Singularity™  Identity: Schwachstellen erkennen, bevor Angreifer sie finden

Singularity™ Identity bietet kontinuierliche Identity Threat Detection and Response (ITDR). Es scannt nach schwachen, exponierten oder kompromittierten Zugangsdaten in lokalen Active Directory-Umgebungen und Cloud-Identitätsanbietern wie Entra ID, Okta, Ping, Duo und SecureAuth. Sie erkennen ungewöhnliche Anstiege bei Fehlanmeldungen, Logins aus ungewöhnlichen Regionen und Kerberosting-Versuche gegen Servicekonten. Außerdem ist Identity Security Posture Management (ISPM) enthalten, sodass Sie laufende Bewertungen Ihrer Identitätssicherheit erhalten – nicht nur Einzelprüfungen.

Purple AI: Natürliche Fragen stellen, schnell Antworten erhalten

Wenn ein Alarm ausgelöst wird, beschleunigt Purple AI die Untersuchung. Stellen Sie einfach eine Frage in Alltagssprache wie „zeige mir alle Systeme, auf die dieses kompromittierte Konto in den letzten 72 Stunden zugegriffen hat“. Sie erhalten korrelierte Ergebnisse mit MITRE ATT&CK-Taktik-Kontext. Laut einer IDC Business Value-Studie erkennen Sicherheitsteams mit Purple AI Bedrohungen 63 % schneller und beheben sie 55 % schneller.

Singularity™  Data Lake und Storyline™  nutzen

Alle Ereignisdaten landen im Singularity™ Data Lake und werden in das Open Cybersecurity Schema Framework (OCSF) normalisiert. Abfragen laufen bis zu 100-mal schneller als bei herkömmlichen SIEMs. Die Storyline-Technologie rekonstruiert dann die gesamte Angriffskette – vom initialen Credential Theft über jede laterale Bewegung, Privilegieneskalation und Datenzugriff – sodass Sie die gesamte Zeitleiste ohne manuelle Korrelation sehen.
Fordern Sie eine SentinelOne-Demo an, um Singularity AI SIEM und Singularity Identity in Aktion zu sehen.

Verwandte Schwachstellen

Broken Authentication überschneidet sich mit und ermöglicht mehrere andere Schwachstellenklassen:

• Broken Access Control (OWASP A01:2021): Authentifizierung prüft, wer Sie sind; Zugriffskontrolle prüft, was Sie tun dürfen. Ein Broken Authentication-Fehler, der Angreifern Zugang zu einem gültigen Konto verschafft, übernimmt dessen Berechtigungen und macht Zugriffskontrolle irrelevant.
• Kryptografische Fehler (OWASP A02:2021): Schwaches Passwort-Hashing, Klartext-Speicherung von Zugangsdaten und fehlerhafte Zertifikatsvalidierung sind kryptografische Fehler, die Authentifizierungskomprimittierung direkt ermöglichen.
• Sicherheitsfehlkonfiguration (OWASP A05:2021): Standardzugangsdaten, zu permissive MFA-Neuregistrierung und zu lange Sitzungs-Timeouts sind Konfigurationsfehler, die Authentifizierungsschwächen schaffen.
• Server-Side Request Forgery (SSRF): SSRF kann mit Authentifizierungsumgehung kombiniert werden, um interne Dienste zu erreichen, die Anfragen vom kompromittierten Server vertrauen.
• Injection-Schwachstellen: SQL Injection gegen Authentifizierungsabfragen kann die Login-Logik vollständig umgehen, indem die Abfrage zur Validierung der Zugangsdaten manipuliert wird.
• Credential Theft (MITRE ATT&CK T1078 Valid Accounts): Die Nutzung gültiger Konten, die durch beliebige Diebstahlmethoden erlangt wurden, entspricht direkt der Post-Exploitation-Phase von Broken Authentication.

Die Behebung von Broken Authentication reduziert nicht nur das Identitätsrisiko isoliert. Stärkere Passwortrichtlinien, durchgesetzte MFA und gehärtete Sitzungssteuerung verringern die gemeinsame Angriffsfläche, auf die Broken Access Control, kryptografische Fehler und Fehlkonfigurationen angewiesen sind.

Verwandte CVEs

CVE-ID	Beschreibung	Schweregrad	Betroffenes Produkt	Jahr
CVE-2025-4427	API-Authentifizierungsumgehung in Mobile Device Management-Plattform ermöglicht nicht authentifizierten Zugriff auf eingeschränkte Funktionen	HOCH	Ivanti Endpoint Manager Mobile	2025
CVE-2025-3248	Fehlende Authentifizierung am Codeausführungs-Endpunkt ermöglicht nicht authentifizierte Remote-Code-Injektion	KRITISCH	Langflow AI Workflow Platform	2025
CVE-2025-0108	Fehlende Authentifizierung an der Management-Weboberfläche ermöglicht nicht authentifizierten administrativen Zugriff	HOCH	Palo Alto PAN-OS	2025
CVE-2024-53704	Unzureichende Authentifizierung in der SSLVPN-Komponente ermöglicht Angreifern das Hijacking aktiver VPN-Sitzungen	HOCH	SonicWall SonicOS	2024
CVE-2024-11639	Authentifizierungsumgehung in der Admin-Konsole ermöglicht nicht authentifizierten Remote-Angreifern vollständigen administrativen Zugriff	KRITISCH	Ivanti Cloud Services Appliance	2024
CVE-2024-1709	Authentifizierungsumgehung über alternativen Pfad ermöglicht vollständige nicht authentifizierte Übernahme der Remote-Support-Plattform	KRITISCH	ConnectWise ScreenConnect	2024
CVE-2023-4966	Sitzungstoken-Offenlegung aus dem Speicher ermöglicht Angreifern das Hijacking authentifizierter Sitzungen und Umgehung von MFA (Citrix Bleed)	KRITISCH	Citrix NetScaler ADC und Gateway	2023
CVE-2023-42793	Authentifizierungsumgehung an kritischen API-Endpunkten führt zu nicht authentifizierter Remote-Codeausführung auf CI/CD-Server	KRITISCH	JetBrains TeamCity	2023
CVE-2023-35078	API-Authentifizierungsumgehung ermöglicht nicht authentifizierten Zugriff auf eingeschränkte Endpunkte und sensible Daten	KRITISCH	Ivanti Endpoint Manager Mobile	2023
CVE-2022-47966	SAML-Authentifizierungsumgehung durch veraltete Apache xmlsec-Bibliothek ermöglicht nicht authentifizierte Remote-Codeausführung	KRITISCH	Zoho ManageEngine (20+ Produkte)	2022
CVE-2022-40684	Authentifizierungsumgehung über alternativen Pfad oder Kanal ermöglicht nicht authentifizierten Angreifern privilegierte Operationen	KRITISCH	Fortinet FortiOS / FortiProxy / FortiSwitchManager	2022
CVE-2022-1388	Fehlende Authentifizierung an der iControl REST API ermöglicht nicht authentifizierten Angreifern die Ausführung beliebiger Systembefehle	KRITISCH	F5 BIG-IP	2022
CVE-2021-35587	Fehlende Authentifizierung in der OpenSSO Agent-Komponente ermöglicht nicht authentifizierte vollständige Systemübernahme via HTTP	KRITISCH	Oracle Access Manager (Fusion Middleware)	2021
CVE-2021-26855	SSRF-Schwachstelle ermöglicht Pre-Authentication-Bypass und nicht authentifizierte Remote-Codeausführung (ProxyLogon)	KRITISCH	Microsoft Exchange Server	2021
CVE-2021-22893	Authentifizierungsumgehung über Windows File Share Browser und Collaboration-Funktionen ermöglicht nicht authentifizierte RCE	KRITISCH	Ivanti Connect Secure (Pulse Connect Secure)	2021
CVE-2020-29583	Undokumentiertes fest codiertes Konto mit unveränderbarem Passwort gewährt nicht authentifizierten vollen Admin-Zugriff via SSH und Web-UI	KRITISCH	Zyxel USG / ATP / VPN Firmware	2020
CVE-2020-13927	Fehlende Authentifizierung an Experimental API ermöglicht nicht authentifizierten Remote-Zugriff und beliebige Codeausführung	KRITISCH	Apache Airflow	2020
CVE-2020-12812	Fehlerhafte Groß-/Kleinschreibung bei Benutzernamen ermöglicht Angreifern die Umgehung der Zwei-Faktor-Authentifizierung auf SSL VPN ohne FortiToken	KRITISCH	Fortinet FortiOS SSL VPN	2020
CVE-2019-25470	Authentifizierungsumgehung am wsdReadForm-Endpunkt ermöglicht das Auslesen und Entschlüsseln aller Benutzerzugangsdaten über fest codierten XOR-Schlüssel	MITTEL	eWON Firmware 12.2–13.0	2019
CVE-2019-25320	SQL Injection im Login-Endpunkt umgeht Authentifizierung vollständig und gewährt nicht authentifizierten Dashboard-Zugriff	KRITISCH	E Learning Script 1.0	2019
CVE-2019-25501	SQL Injection über POST-Parameter ermöglicht Authentifizierungsumgehung und unautorisierten Datenbankzugriff	HOCH	Simplejobscript	2019

Fazit

Broken Authentication bleibt einer der am häufigsten ausgenutzten Erstzugriffswege bei Unternehmensvorfällen. Versagen Ihre Authentifizierungskontrollen, können Angreifer schwache Passwörter, fragile Sitzungen, MFA-Umgehungen oder fehlende Prüfungen in vollständige Kontenkompromittierung umwandeln. 

Sie reduzieren dieses Risiko durch phishing-resistente MFA, moderne Passwortrichtlinien, sichere Sitzungsverwaltung und Identitätstransparenz, die zeigt, wie gestohlene Zugangsdaten genutzt werden.

FAQs

Was ist eine Broken Authentication-Schwachstelle?

Broken Authentication ist ein Identitätsvertrauensfehler. Er tritt auf, wenn eine Anwendung nicht zuverlässig verifizieren kann, wer ein Benutzer ist, oder diese Identität nach dem Login nicht sicher aufrechterhalten kann. 

In der Praxis umfasst das schwache Anmeldeüberprüfungen, anfällige Wiederherstellungsprozesse und Fehler in der Sitzungsverwaltung, die es Angreifern ermöglichen, als legitime Benutzer zu agieren.

Ist Broken Authentication Teil der OWASP Top 10?

Ja. OWASP hat diese Kategorie seit Beginn der Top 10 im Jahr 2004 aufgenommen. Die Namensänderungen sind relevant: Der Wechsel von "Broken Authentication" zu "Identification and Authentication Failures" und dann "Authentication Failures" zeigt, dass das Risiko nun Passwörter, MFA, Sitzungsstatus, Föderation und alternative Zugriffspfade umfasst.

Kann Broken Authentication aus der Ferne ausgenutzt werden?

In der Regel ja. Die Vertrauensgrenze liegt oft bei einem internetzugänglichen Login, API, VPN-Gateway, SaaS-Konto oder einer Management-Oberfläche. 

Angreifer können gültige Anmeldedaten wiederverwenden, exponierte Authentifizierungspfade missbrauchen oder Sitzungen kapern, wodurch die Aktivität wie normaler Zugriff und nicht wie ein traditioneller Exploit erscheint.

Welche Arten von Anwendungen sind am anfälligsten für Broken Authentication?

Am höchsten gefährdet sind Systeme, die Identitätsentscheidungen für andere Systeme treffen: Webanwendungen, APIs, Cloud-Konsolen, SSO-verbundene Dienste und Perimeter-Appliances. 

Eine einfache Regel gilt: Je breiter ein Konto nach dem Login agieren kann, desto gravierender wird ein Authentifizierungsfehler.

Wie entdecken Angreifer typischerweise Broken Authentication?

Sie kombinieren in der Regel Tests mit Wiederverwendung. Tests zeigen schwache Sperrmechanismen, Wiederherstellungs-, MFA- oder Sitzungsverhalten. Wiederverwendung betrifft gestohlene Anmeldedaten, Tokens oder bekannte CVEs, die bereits funktionieren. 

Das macht die Entdeckung relativ kostengünstig, da Angreifer oft keinen neuen Exploit benötigen, um einzudringen.

Was sind die ersten Anzeichen einer Ausnutzung von Broken Authentication?

Frühe Anzeichen sind meist Muster, keine einzelnen Alarme. Häufige Indikatoren sind verteilte Login-Fehler, unmögliche Reisen, ungewöhnliche Wiederherstellungsaktivitäten, wiederholte MFA-Aufforderungen und neues Sitzungsverhalten nach erfolgreichem Login. 

Das wichtigste Signal ist eine Abfolge, die Authentifizierungs-, Sitzungs- und Berechtigungsereignisse überschreitet.

Wie schwerwiegend ist Broken Authentication im Vergleich zu anderen Schwachstellen?

Sie ist schwerwiegend, weil sie die Kontrolle unterbricht, die alle anderen Kontrollen absichert. Wenn die Authentifizierung fehlschlägt, kann ein Angreifer normalen Benutzerzugriff, privilegierten Zugriff oder föderiertes Vertrauen in nachgelagerte Systeme erlangen. 

Dieser größere Wirkungskreis ist der Grund, warum Missbrauch von Anmeldedaten und Authentifizierungsumgehungen mit folgenschweren Sicherheitsvorfällen verbunden sind.

Kann Broken Authentication zu einer vollständigen Systemkompromittierung führen?

Ja. Authentifizierungsfehler sind oft der Einstiegspunkt, nicht der Endzustand. Einmal im System können Angreifer sich lateral bewegen, Privilegien ausweiten, auf Cloud-Ressourcen zugreifen oder über vertrauenswürdige Identitätskanäle persistieren. 

Ein einziges kompromittiertes Konto kann schnell zu einem organisationsweiten Zugriffsproblem werden.

Ist Broken Authentication mit automatisierten Tools leicht zu erkennen?

Nur teilweise. Automatisierte Tests sind nützlich, um schwache Sperrmechanismen, Wiederherstellungsfehler, fehlende Kontrollen und fest codierte Anmeldedaten zu finden. Sie sind weniger effektiv, wenn Angreifer gültige Anmeldedaten oder gestohlene Tokens verwenden, da diese Aktionen legitim erscheinen können. 

Deshalb sind Identitätsüberwachung und korrelierte Analysen über mehrere Ebenen hinweg wichtig.

Welche Branchen sind am stärksten von Broken Authentication bedroht?

Am stärksten gefährdet sind Branchen, in denen authentifizierter Zugriff direkt zu regulierten Daten, Geldtransfers, administrativer Kontrolle oder kritischen Operationen führt. Finanzdienstleister, Behörden, Gesundheitswesen, Cloud-orientierte Unternehmen und Betreiber von Infrastrukturen passen in dieses Muster. 

Der gemeinsame Risikofaktor ist der Wert und die Reichweite dessen, was ein vertrauenswürdiges Konto freischalten kann.