Broken Authentication

Der Anmeldebildschirm ist die Eingangstür Ihrer Anwendung, und genau diese Tür erweist sich in der Praxis oft als schwächste Stelle. Broken Authentication steht als Identification and Authentication Failures in den OWASP Top 10 und umfasst alle Wege, auf denen Angreifer die Identitätsprüfung aushebeln, von Brute Force bis zu gefälschten Sitzungen. Im Folgenden lesen Sie, wie solche Angriffe ablaufen und wie Sie Anmeldung und Sitzungsverwaltung sauber aufsetzen.

Was ist Broken Authentication?

Broken Authentication ist der Sammelbegriff für Schwachstellen in der Art, wie eine Anwendung feststellt, wer sich anmeldet, und wie sie diesen angemeldeten Zustand anschließend schützt. Es handelt sich also nicht um einen einzelnen Fehler, sondern um eine ganze Familie: schwache Passwortanforderungen, unsichere Passwortspeicherung, Anmeldeformulare ohne Bremse für die Zahl der Versuche, vorhersagbare Session-Tokens und nachlässige Abläufe zum Zurücksetzen des Passworts. In allen Varianten ist das Ergebnis dasselbe: Jemand erhält Zugriff auf ein Konto, das ihm nicht gehört.

Ein Vergleich aus dem Alltag: ein Hotel, in dem die Rezeption jedem einen Zimmerschlüssel aushändigt, der eine Zimmernummer nennt, ohne je einen Ausweis zu verlangen. Oder ein Hotel, das zwar kontrolliert, aber Schlüsselkarten mit fortlaufenden Nummern ausgibt: Wer Karte 214 besitzt, weiß, wie 215 aussieht. In beiden Fällen ist nicht das Schloss defekt, sondern der Prozess darum herum.

Wichtig ist dabei: Authentifizierung ist mehr als das Anmeldeformular. Auch Passwortspeicherung, Sitzungsverwaltung, Angemeldet-bleiben-Cookies, API-Schlüssel und die Passwort-Wiederherstellung gehören zur selben Kette, und ein Angreifer sucht sich immer das schwächste Glied.

Wie funktioniert ein Angriff auf die Authentifizierung?

Angreifer müssen selten etwas knacken; meist benutzen sie die Eingangstür so, wie sie gebaut wurde. Beim Credential Stuffing probieren sie geleakte Kombinationen aus E-Mail-Adresse und Passwort aus früheren Datenlecks automatisiert durch. Bei Brute Force feuert ein Skript Tausende Passwörter pro Minute ab. Und wenn die Anwendung selbst schwache Tokens ausgibt, können sie sich das Raten ganz sparen. Das Beispiel unten zeigt einen Login-Endpunkt, der drei klassische Fehler vereint.

Verwundbar:

// Passwort im Klartext, geschwätzige Fehlermeldungen, vorhersagbares Token
app.post("/login", async (req, res) => {
  const user = await db.findUserByEmail(req.body.email);
  if (!user) {
    return res.status(401).send("Unbekannte E-Mail-Adresse");
  }
  if (user.password !== req.body.password) {
    return res.status(401).send("Falsches Passwort");
  }

  // "Session-Token": Base64 der Benutzer-ID
  const token = Buffer.from("user:" + user.id).toString("base64");
  res.cookie("session", token);
  res.send("Angemeldet");
});

Hier läuft gleich mehreres schief. Die zwei unterschiedlichen Fehlermeldungen verraten, ob eine E-Mail-Adresse existiert (User Enumeration): ein Angreifer erstellt so zuerst eine Liste gültiger Konten und testet geleakte Passwörter dann gezielt gegen genau diese. Ein Limit für Anmeldeversuche fehlt, das Durchprobieren darf also endlos weiterlaufen. Das Passwort liegt zudem im Klartext in der Datenbank. Ein einziges Datenleck, und jedes Passwort ist öffentlich. Der gravierendste Fehler ist jedoch das Session-Token: Base64 ist keine Verschlüsselung, sondern eine Kodierung, die jeder umkehren kann. Ein Angreifer kodiert einfach selbst den Text user:1, setzt das Ergebnis dXNlcjox als Cookie und ist als Benutzer 1 angemeldet, häufig ein Administrator, ohne je ein Passwort zu kennen.

Die sichere Variante behebt alle drei Schwächen: Passwörter werden als Hash verglichen, die Fehlermeldung gibt nichts preis, die Versuche sind begrenzt, und das Session-Token stammt aus einem kryptografisch sicheren Generator.

Sicher:

// Hash-Vergleich, generische Fehlermeldung, Limit, zufälliges Token
app.post("/login", loginRateLimiter, async (req, res) => {
  const user = await db.findUserByEmail(req.body.email);
  const hash = user ? user.passwordHash : DUMMY_HASH;
  const valid = await bcrypt.compare(req.body.password, hash);

  if (!user || !valid) {
    return res.status(401).send("Ungültige Zugangsdaten");
  }

  // Session-Token: 32 zufällige Bytes, serverseitig gespeichert
  const sessionId = crypto.randomBytes(32).toString("hex");
  await sessions.create(sessionId, user.id);
  res.cookie("session", sessionId, {
    httpOnly: true,
    secure: true,
    sameSite: "lax",
  });
  res.send("Angemeldet");
});

Beachten Sie das Detail mit DUMMY_HASH: Auch wenn das Konto nicht existiert, führt der Code einen Hash-Vergleich durch. So dauert jeder Anmeldeversuch gleich lang, und aus der Antwortzeit lässt sich nicht ablesen, welche E-Mail-Adressen existieren. Das Session-Token besteht nun aus 256 Bit Zufall, der nur serverseitig einem Benutzer zugeordnet ist; Raten oder Zurückrechnen ist aussichtslos. Die Cookie-Attribute halten schließlich Skripte und Mitleser vom Token fern.

Welche Auswirkungen hat Broken Authentication?

Der unmittelbare Schaden ist die Kontoübernahme. Ein Angreifer, der als Kunde angemeldet ist, sieht persönliche Daten, Bestellhistorie und hinterlegte Zahlungsmethoden und kann im Namen des Opfers handeln. Handelt es sich um ein Administratorkonto, verschiebt sich die Auswirkung von einem Konto auf die gesamte Anwendung: die Daten aller Benutzer, sämtliche Einstellungen und oft ein Sprungbrett in die darunterliegende Infrastruktur.

Im großen Maßstab wird daraus ein Geschäftsrisiko. Credential Stuffing lässt sich billig automatisieren; ein einziges schwaches Anmeldeformular kann daher binnen Tagen Tausende übernommener Konten liefern, gefolgt von Betrug, Rückbuchungen und einem meldepflichtigen Datenleck nach DSGVO. Der Reputationsschaden kommt obendrauf: Benutzer verzeihen ein gehacktes Konto selten.

Besonders tückisch ist, wie unauffällig diese Angriffe sind. Eine gekaperte Sitzung oder eine erfolgreiche Credential-Stuffing-Anmeldung sieht in den Protokollen aus wie ein gewöhnlicher Benutzer, der sich anmeldet. Weil die Folgen von einem übernommenen Konto bis zur vollständigen Kompromittierung der Anwendung reichen, bewegt sich der Schweregrad von hoch bis kritisch.

Wie erkennen Sie Broken Authentication?

Tester beginnen mit dem, was die Anwendung preisgibt: Unterschiede in Fehlermeldungen oder Antwortzeiten, die verraten, welche Konten existieren. Danach folgt die Bremse für Versuche: akzeptiert das Formular Hunderte Passwörter hintereinander ohne Sperre oder Verzögerung? Auch Session-Tokens werden untersucht, indem man Dutzende davon sammelt und auf Muster, Länge und Vorhersagbarkeit analysiert. Zuletzt der Lebenszyklus: Bleibt eine Sitzung nach dem Abmelden oder einer Passwortänderung gültig, und wie streng ist der Reset-Ablauf?

Automatisierte Scanner erfassen bestenfalls die oberflächlichen Signale; die Logik dahinter erfordert Handarbeit. Genau dieses Terrain geht AssistSec bei einem Penetrationstest systematisch durch, von der Token-Analyse bis zum Reset-Ablauf, damit Sie genau wissen, über welchen Weg ein Angreifer tatsächlich in ein Konto gelangt.

Wie verhindern Sie Broken Authentication?

• Aktivieren Sie Multi-Faktor-Authentifizierung (MFA), mindestens für Administratoren. Ein geleaktes oder erratenes Passwort reicht dann nicht mehr aus.
• Speichern Sie Passwörter als Hash mit bcrypt, scrypt oder Argon2, nie im Klartext und nie mit schnellen Hashes wie MD5 oder SHA-1.
• Begrenzen Sie Anmeldeversuche mit Rate Limiting, ansteigenden Verzögerungen oder einer vorübergehenden Sperre, pro Konto und pro IP-Adresse.
• Halten Sie Fehlermeldungen generisch, unabhängig davon, ob die E-Mail-Adresse existiert, und halten Sie auch die Antwortzeiten konstant.
• Erzeugen Sie Session-Tokens mit einem kryptografisch sicheren Generator, speichern Sie sie serverseitig und versehen Sie Cookies mit den Attributen httpOnly, secure und sameSite.
• Erneuern Sie das Session-Token direkt nach der Anmeldung und machen Sie alle Sitzungen beim Abmelden und nach einer Passwortänderung ungültig.
• Machen Sie Reset-Tokens einmalig verwendbar und kurzlebig und bestätigen Sie sensible Änderungen über einen zweiten Kanal.
• Prüfen Sie neue Passwörter gegen Listen geleakter Passwörter, statt sich allein auf Komplexitätsregeln zu verlassen.
• Lassen Sie die gesamte Authentifizierungskette regelmäßig testen, einschließlich Sitzungsverwaltung und Reset-Abläufen. Dort stecken die Fehler, die Scanner übersehen.