Mehrfaktorauthentifizierung wird nicht erzwungen

Zwei-Faktor-Authentifizierung anzubieten und Zwei-Faktor-Authentifizierung zu erzwingen sind zwei sehr unterschiedliche Maßnahmen mit sehr unterschiedlichen Ergebnissen. Die erste macht sich gut in der Dokumentation; die zweite schützt Ihre Nutzer. Im Folgenden lesen Sie, warum die freiwillige Variante so wenig bewirkt und wie Sie die Pflicht einführen, ohne dass daraus eine Störung wird.

Was bedeutet “nicht erzwungen”?

Nicht erzwungene Mehrfaktorauthentifizierung ist ein zweiter Faktor, den die Anwendung unterstützt, aber nicht verlangt. Nutzer können ihn einschalten; sie müssen es nicht. Die Funktion ist vorhanden, der Schutz ist optional.

In der Praxis gibt es drei Erscheinungsformen, die alle auf dasselbe hinauslaufen. Die erste ist die rein optionale Variante, versteckt in einer Einstellungsmaske, die wenige Nutzer je öffnen. Die zweite ist die Variante, die für gewöhnliche Nutzer verpflichtend ist, für Administratoren jedoch nicht, weil diese “sich ja auskennen”, während gerade jene Konten die meisten Rechte tragen. Die dritte ist die Variante, die in der Weboberfläche erzwungen wird, nicht aber auf der API, wodurch sich die Pflicht mit einem einzigen anderen Endpunkt umgehen lässt.

Vergleichen Sie es mit einem Gebäude, in dem Besucher sich ausweisen dürfen, wenn sie möchten. Die Maßnahme besteht, es gibt einen Tresen, es gibt ein Verfahren. Nur entscheidet der Besucher, ob er mitmacht, und das ist genau die falsche Partei, um ihr diese Wahl zu überlassen.

Wie umgeht ein Angreifer optionale MFA?

Verwundbar:

app.post('/anmelden', async (req, res) => {
  const nutzer = await pruefeZugangsdaten(req.body);
  if (!nutzer) return res.status(401).send('Ungültige Daten');

  if (nutzer.mfaAktiv) {                     // nur wenn der Nutzer es wollte
    req.session.zweiterFaktorFuer = nutzer.id;
    return res.redirect('/anmelden/verifizierung');
  }

  req.session.userId = nutzer.id;            // sonst direkt hinein
  res.send('Willkommen');
});

// Die API kennt diesen Schritt überhaupt nicht
app.post('/api/token', async (req, res) => {
  const nutzer = await pruefeZugangsdaten(req.body);
  if (!nutzer) return res.sendStatus(401);
  res.json({ token: erstelleToken(nutzer) });
});

Zwei Probleme zugleich. Die Verifizierung hängt an einer Einstellung, die der Nutzer selbst aktiviert haben muss, und der zweite Endpunkt überspringt den Schritt vollständig. Selbst ein Nutzer, der MFA ordentlich eingeschaltet hat, ist über /api/token allein mit einem Passwort erreichbar:

POST /api/token HTTP/1.1
Content-Type: application/json

{"email":"admin@firma.de","passwort":"<aus einem früheren Datenleck>"}

HTTP/1.1 200 OK
{"token":"eyJhbGciOiJIUzI1NiIs..."}

Die gesamte Maßnahme ist mit einer Anfrage an eine andere Adresse umgangen.

Sicher:

// Eine Stelle entscheidet, ob jemand eine Sitzung erhält
async function darfSitzungErhalten(nutzer) {
  const pflicht = nutzer.rolle === 'admin'
    || nutzer.rolle === 'finanzen'
    || RICHTLINIE.mfaFuerAlle;

  if (!nutzer.mfaAktiv && pflicht) return { status: 'einrichtung-erforderlich' };
  if (nutzer.mfaAktiv) return { status: 'verifizierung-erforderlich' };
  return { status: 'ok' };
}

app.post('/anmelden', async (req, res) => {
  const nutzer = await pruefeZugangsdaten(req.body);
  if (!nutzer) return res.status(401).send('Ungültige Daten');

  const { status } = await darfSitzungErhalten(nutzer);
  if (status === 'einrichtung-erforderlich') {
    req.session.mfaEinrichtenFuer = nutzer.id;      // eingeschränkter Zustand
    return res.redirect('/mfa/einrichten');
  }
  if (status === 'verifizierung-erforderlich') {
    req.session.zweiterFaktorFuer = nutzer.id;
    return res.redirect('/anmelden/verifizierung');
  }
  req.session.regenerate(() => { req.session.userId = nutzer.id; res.send('Willkommen'); });
});

Der entscheidende Unterschied besteht darin, dass es nur noch eine Stelle gibt, an der über die Vergabe einer Sitzung entschieden wird, und dass jeder Kanal, Weboberfläche, API und mobile Anwendung, dort hindurchgeht. Ein Nutzer, für den MFA verpflichtend ist, sie aber noch nicht eingerichtet hat, landet in einem eingeschränkten Zustand, in dem er allein dies regeln kann.

Welche Auswirkungen hat nicht erzwungene MFA?

Der Schweregrad ist mittel bis hoch, abhängig davon, welche Konten ungeschützt bleiben. In der Praxis ist das eine ungünstige Auswahl: Nutzer, die MFA freiwillig einschalten, sind meist die sicherheitsbewussteren, während die Konten mit dem größten Risiko häufig jenen von vielbeschäftigten Führungskräften und Administratoren gehören.

Das Ergebnis ist, dass Sie zwar die Maßnahme haben, aber nicht den Schutz. Bei einem Angriff mit Zugangsdaten aus einem früheren Datenleck spielt es keine Rolle, welcher Prozentsatz Ihrer Nutzer einen zweiten Faktor besitzt; es zählt, ob das Konto, das der Angreifer trifft, einen hatte. Bei Tausenden automatisierten Versuchen ist das eine Frage der Statistik.

Hinzu kommt eine organisatorische Wirkung, die schwerer wiegt als die technische. Eine optionale Maßnahme vermittelt der Organisation das Gefühl, MFA sei “geregelt”. In Audits, in Berichten und in Gesprächen mit Kunden wird das ebenso dargestellt. Der Unterschied zwischen verfügbar und verpflichtend bleibt dabei oft unerwähnt, wodurch das Risiko unsichtbar statt gelöst wird.

Wie spürt man nicht erzwungene MFA auf?

Ein Tester prüft zunächst, ob MFA verfügbar ist und ob sie verlangt wird, und für welche Rollen. Anschließend wird versucht, die Pflicht zu umgehen.

Das geschieht über einige feste Wege. Kann ein Konto mit eingeschalteter MFA dennoch über die API, über eine ältere API-Version oder über einen mobilen Endpunkt eine Sitzung oder ein Token erhalten? Lässt sich die Verifizierungsmaske überspringen, indem nach dem Passwortschritt unmittelbar eine geschützte Route aufgerufen wird? Gibt es eine Funktion “dieses Gerät merken”, die die Verifizierung über einen langen Zeitraum überspringt, und ist sie an das Gerät gebunden? Funktioniert der Weg zur Passwortwiederherstellung ohne zweiten Faktor, wodurch die gesamte Maßnahme über einen Umweg entfiele? AssistSec prüft zusätzlich ausdrücklich die Konten mit den höchsten Rechten, denn eine Ausnahme für Administratoren kommt in der Praxis am häufigsten vor und wiegt zugleich am schwersten.

Wie verhindert man nicht erzwungene MFA?

• Machen Sie Mehrfaktorauthentifizierung für Administratoren und für Rollen mit Zugriff auf sensible Daten verpflichtend.
• Führen Sie die Pflicht schrittweise ein, mit Ankündigung, Übergangsfrist und einer Einrichtungsmaske nach der Anmeldung.
• Entscheiden Sie an einer zentralen Stelle, ob jemand eine Sitzung erhält, damit jeder Kanal denselben Regeln folgt.
• Erzwingen Sie die Verifizierung auf der API, auf mobilen Endpunkten und in älteren Versionen, nicht nur in der Weboberfläche.
• Schließen Sie veraltete Protokolle und Integrationen, die eine Authentifizierung ohne zweiten Faktor erlauben.
• Binden Sie eine Funktion “dieses Gerät merken” an das Gerät, versehen Sie sie mit einer begrenzten Laufzeit und machen Sie sie widerrufbar.
• Verlangen Sie den zweiten Faktor auch bei der Passwortwiederherstellung, damit dieser Weg kein Umweg wird.
• Erfassen Sie Ausnahmen mit einem Enddatum und begrenzen Sie die Rechte dieser Konten.
• Berichten Sie regelmäßig, welcher Anteil der Konten tatsächlich einen zweiten Faktor nutzt, aufgeschlüsselt nach Rolle.