Mehrfaktorauthentifizierung fehlt

Solange ein Konto allein mit einem Passwort geschützt ist, ist die Absicherung nur so stark wie ein Geheimnis, das Ihr Nutzer möglicherweise auch anderswo verwendet hat. Darin liegt der Kern des Problems: Sie sichern Ihre Anwendung mit einer Angabe, über die Sie keine Kontrolle haben. Im Folgenden lesen Sie, was ein zweiter Faktor daran ändert und warum die Wahl der richtigen Form über eine echte und eine scheinbare Hürde entscheidet.

Was ist Mehrfaktorauthentifizierung?

Mehrfaktorauthentifizierung (MFA) bedeutet, dass ein Nutzer seine Identität mit Nachweisen aus mehr als einer Kategorie belegt: etwas, das er weiß (ein Passwort), etwas, das er besitzt (einen Schlüssel oder ein Telefon), und etwas, das er ist (einen Fingerabdruck oder Gesichtsscan). Es kommt auf die Kombination der Kategorien an, nicht auf die Zahl der Schritte; zwei Passwörter nacheinander sind keine MFA.

Der zugrunde liegende Gedanke ist, dass es plausibel ist, dass ein Nachweis in falsche Hände gerät, und unwahrscheinlich, dass dies für zwei zugleich gilt. Ein Passwort gelangt über ein Datenleck bei einem anderen Dienst nach außen, wird erraten oder auf einer nachgebauten Anmeldeseite preisgegeben. Ein physischer Schlüssel oder ein gekoppeltes Telefon folgt nicht von selbst mit.

Es ist der Banktresor, für den zwei Schlüssel zugleich nötig sind: der des Kunden und der des Bankmitarbeiters. Nicht weil ein Schlüssel schlecht wäre, sondern weil das Risiko, dass beide zugleich bei derselben Person landen, wesentlich kleiner ist.

Welche Formen bieten wirklich Schutz?

Nicht jeder zweite Faktor ist gleich stark, und der Unterschied liegt vor allem in der Widerstandsfähigkeit gegen Phishing.

Verwundbar:

// Ein Faktor, und der Zugang steht
app.post('/anmelden', async (req, res) => {
  const nutzer = await nutzerRepo.findeUeberEmail(req.body.email);
  if (!nutzer || !await argon2.verify(nutzer.hash, req.body.passwort)) {
    return res.status(401).send('Ungültige Daten');
  }

  req.session.userId = nutzer.id;
  res.send('Willkommen');         // vollständiger Zugang
});

Wer das Passwort hat, ist drin. Und dieses Passwort stammt in der Praxis aus einer von drei Quellen: einem Datenleck bei einem anderen Dienst, bei dem der Nutzer dasselbe Passwort verwendete, einem gelungenen Rateversuch oder einer Phishing-Seite, auf der er es selbst eingegeben hat.

Sicher:

app.post('/anmelden', async (req, res) => {
  const nutzer = await nutzerRepo.findeUeberEmail(req.body.email);
  if (!nutzer || !await argon2.verify(nutzer.hash, req.body.passwort)) {
    return res.status(401).send('Ungültige Daten');
  }

  // Noch keine Sitzung: nur ein kurzlebiger, eingeschränkter Zwischenzustand
  req.session.zweiterFaktorFuer = nutzer.id;
  req.session.laeuftAbAm = Date.now() + 5 * 60 * 1000;
  res.redirect('/anmelden/verifizierung');
});

app.post('/anmelden/verifizierung', async (req, res) => {
  const id = req.session.zweiterFaktorFuer;
  if (!id || Date.now() > req.session.laeuftAbAm) {
    return res.status(401).send('Verifizierung abgelaufen');
  }
  if (!await verifizierungStimmt(id, req.body)) {          // Passkey oder TOTP
    await erfasseFehlversuch(id);
    return res.status(401).send('Verifizierung fehlgeschlagen');
  }

  req.session.regenerate(() => {
    req.session.userId = id;                              // erst jetzt eine echte Sitzung
    res.redirect('/');
  });
});

Das entscheidende Detail ist, dass nach dem Passwort noch keine brauchbare Sitzung besteht. Der Zwischenzustand berechtigt nur zum Abschluss der Verifizierung, ist kurzlebig und gewährt keinerlei Zugriff auf Daten. Ein häufiger Fehler besteht darin, die Sitzung sofort anzulegen und den zweiten Faktor nur in der Oberfläche zu verlangen; dieser lässt sich dann mit einer direkten Anfrage umgehen.

Bei der Verifizierung selbst gehen die Stärken weit auseinander. Passkeys und Hardwareschlüssel nach dem WebAuthn-Standard sind phishingresistent, da der Schlüssel an Ihre Domain gebunden ist. Eine Authenticator-App mit Einmalcodes ist ein guter Mittelweg. SMS ist die schwächste Form, da sich der Code leicht auf einer nachgebauten Seite abfragen und unmittelbar weiterreichen lässt.

Welche Auswirkungen hat fehlende MFA?

Der Schweregrad ist mittel bis hoch, abhängig davon, was hinter der Anwendung liegt und ob es um Administratorzugriff geht. Diesen Befund zeichnet aus, dass der Angriff gar nicht in Ihrer Anwendung beginnen muss.

Beim Credential Stuffing werden Kombinationen aus früheren Datenlecks automatisiert durchprobiert. Da die Wiederverwendung von Passwörtern weit verbreitet ist, ergibt das zuverlässig einen Prozentsatz erfolgreicher Anmeldungen, ohne dass an Ihrer Absicherung etwas falsch wäre. Beim Phishing gibt der Nutzer sein Passwort freiwillig auf einer nachgebauten Seite preis. In beiden Fällen gibt es keine Schwachstelle in Ihrem Code; es gibt lediglich nichts, was das gestohlene Passwort aufhält.

Die Folgen richten sich danach. Bei einem gewöhnlichen Nutzerkonto geht es um Zugriff auf personenbezogene Daten und die Möglichkeit, im Namen dieser Person zu handeln. Bei einem Administratorkonto geht es um das gesamte System. Und da der Angreifer mit gültigen Zugangsdaten hereinkommt, sieht seine Aktivität in den Protokollen wie normale Nutzung aus, was die Erkennung erheblich erschwert.

Wie spürt man fehlende MFA auf?

Die erste Feststellung ist einfach: Bietet die Anwendung einen zweiten Faktor an, und wenn ja, welche Formen? Danach beginnt die Untersuchung, die wirklich etwas aussagt.

Ein Tester prüft, ob der zweite Faktor serverseitig erzwungen wird, indem er die Verifizierungsmaske überspringt und mit der nach dem Passwortschritt entstandenen Sitzung unmittelbar eine geschützte Route aufruft. Funktioniert das, ist die MFA kosmetisch. Ebenso wird geprüft, ob der Zwischenzustand kurzlebig ist, ob die Zahl der Verifizierungsversuche begrenzt wird und ob Einmalcodes tatsächlich nur einmal verwendbar sind. Auch die Umwege erhalten Aufmerksamkeit: die Funktion zur Passwortwiederherstellung, Wiederherstellungscodes sowie API-Endpunkte oder ältere Protokolle, die nur nach einem Passwort fragen. Letzteres ist ein klassischer Befund: eine Anwendung mit ordentlicher MFA in der Weboberfläche, deren API dieselben Zugangsdaten ohne zweiten Faktor akzeptiert. AssistSec prüft diese Wege ausdrücklich, denn der schwächste Eingang bestimmt, wie stark die Authentifizierung wirklich ist.

Wie verhindert man fehlende MFA?

• Bieten Sie Mehrfaktorauthentifizierung für alle Konten an und machen Sie sie für Administratoren und sensible Rollen verpflichtend.
• Bevorzugen Sie Passkeys oder Hardwareschlüssel nach WebAuthn; diese sind gegen Phishing beständig.
• Nutzen Sie als Alternative eine Authenticator-App mit zeitbasierten Codes und SMS nur als letzte Option.
• Legen Sie eine vollwertige Sitzung erst an, nachdem der zweite Faktor verifiziert wurde, nicht davor.
• Erzwingen Sie die Verifizierung serverseitig auf jeder Route, einschließlich APIs und älterer Protokolle.
• Begrenzen Sie die Zahl der Verifizierungsversuche und machen Sie Einmalcodes nach Gebrauch sofort ungültig.
• Sichern Sie den Wiederherstellungsweg ebenso stark ab wie den Anmeldeweg; sonst verlagern Sie das Problem nur.
• Verwenden Sie Nummernabgleich bei Push-Benachrichtigungen, um MFA-Müdigkeit entgegenzuwirken.
• Verlangen Sie den zweiten Faktor erneut vor sensiblen Vorgängen sowie bei einem unbekannten Gerät oder ungewöhnlichen Standort.