Anwendung nutzt Basic Authentication

Basic Authentication ist einer der ältesten Bestandteile von HTTP und weiterhin im Einsatz: Es lässt sich mit einer einzigen Konfigurationszeile einrichten und funktioniert überall. Genau diese Einfachheit macht es für eine moderne Anwendung ungeeignet, denn es enthält keinerlei Vorkehrung für das, was wir heute von einer Authentifizierung erwarten. Das verdient eine Erklärung.

Was ist Basic Authentication?

Bei HTTP Basic Authentication sendet der Client Benutzername und Passwort in einem Header, durch einen Doppelpunkt verbunden und anschließend in Base64 kodiert. Der Server dekodiert das, prüft die Kombination und entscheidet. Der Browser merkt sich die Daten danach für den Rest der Sitzung und sendet sie bei jeder weiteren Anfrage automatisch erneut mit.

Das häufigste Missverständnis betrifft diese Kodierung. Base64 ist keine Verschlüsselung, sondern eine Möglichkeit, Daten in ein Textformat zu bringen; das Zurückrechnen ist eine Sache von Sekundenbruchteilen und benötigt keinerlei Schlüssel. Basic am9objpQNHNzdzByZCE= ist nichts anderes als john:P4ssw0rd! in einer anderen Schreibweise.

Ein Brief in Blockschrift ist nicht geheimer als derselbe Brief in Schreibschrift. Die Form unterscheidet sich, die Lesbarkeit nicht.

Warum ist Basic Authentication ungeeignet?

Verwundbar:

GET /verwaltung/berichte HTTP/1.1
Host: portal.example
Authorization: Basic am9objpQNHNzdzByZCE=

Dieser Header geht bei jeder Anfrage mit: bei jeder Seite, jedem Bild, jedem API-Aufruf. Das ist ein wesentlicher Unterschied zu einem Session-Cookie, das ein vorübergehender Verweis auf eine Sitzung auf dem Server ist. Hier reist das Passwort selbst, Hunderte Male je Besuch.

Das vergrößert jede Form der Preisgabe. Geht eine einzige Anfrage über eine unverschlüsselte Verbindung, liegt das Passwort offen. Landet der Header in einer Protokolldatei eines Proxys oder in einem Fehlerbericht, steht das Passwort darin. Und speichert ein zwischengeschaltetes System es zur Fehlersuche, steht es auch dort.

Darüber hinaus fehlt alles, was Sie zur Verwaltung der Authentifizierung brauchen. Ein zweiter Faktor ist nicht möglich. Es gibt keine Sitzung, die ablaufen kann. Es gibt keine Möglichkeit, den Zugang ohne Passwortwechsel zu entziehen. Es gibt keine saubere Abmeldefunktion, da der Browser die Daten weiter mitsendet. Und da jede Anfrage ein vollständiger Anmeldeversuch ist, ist das Begrenzen der Versuche umständlich.

Sicher:

// Ein echter Anmeldeablauf mit Sitzung
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) {
    req.session.zweiterFaktorFuer = nutzer.id;
    return res.redirect('/anmelden/verifizierung');
  }
  req.session.regenerate(() => {
    req.session.userId = nutzer.id;
    res.cookie('__Host-sid', req.sessionID, {
      httpOnly: true, secure: true, sameSite: 'strict', path: '/',
      maxAge: 30 * 60 * 1000,
    });
    res.redirect('/');
  });
});

Das Passwort geht nun genau einmal über die Leitung, bei der Anmeldung. Danach wird ein Sitzungsverweis mitgesendet, der abläuft, den Sie widerrufen können, der einen zweiten Faktor zulässt und der beim Abmelden vernichtet wird. Für maschinelle Anbindungen verwenden Sie ein Token oder einen API-Schlüssel, den Sie rotieren können, ohne das Passwort einer Person zu ändern.

Welche Auswirkungen hat Basic Authentication?

Der Schweregrad reicht von mittel bis hoch, wobei das Vorhandensein von TLS am stärksten ins Gewicht fällt. Ohne Verschlüsselung ist das Risiko unmittelbar: Jeder im Netzwerkpfad liest das Passwort mit, und da es bei jeder Anfrage mitgeht, genügt eine einzige abgefangene Anfrage.

Mit TLS ist das größte Risiko beseitigt, die Verwaltungsfragen bleiben jedoch. Ohne zweiten Faktor ruht der Zugang vollständig auf dem Passwort, und dieses Passwort kann anderswo bereits nach außen gelangt sein. Ohne Widerrufsmöglichkeit behält ein Mitarbeiter den Zugang, bis jemand das Passwort ändert. Ohne Sitzung gibt es kein Zeitlimit, ein unbeaufsichtigter Browser behält den Zugang also. Und ohne Abmeldefunktion kann der Nutzer diese Lage nicht selbst beenden.

Es gibt einen weiteren, häufig unterschätzten Aspekt: Da das Passwort bei jeder Anfrage mitgeht, landet es an weit mehr Stellen, als Sie erwarten. Proxyprotokolle, Überwachungssysteme, Fehlerberichte und Netzwerkmitschnitte enthalten dann sämtlich den Header und damit das Passwort in einer Form, die jeder zurücklesen kann.

Wie spürt man Basic Authentication auf?

Das Vorhandensein ist unmittelbar sichtbar: eine Antwort mit 401 und einem WWW-Authenticate: Basic-Header oder ein Browserfenster, das nach Benutzername und Passwort fragt, statt einer Anmeldeseite in der Anwendung selbst.

Danach werden die Umstände betrachtet. Wird die Verbindung über TLS erzwungen, oder ist der Dienst auch über HTTP erreichbar? Wurden die Zugangsdaten gegenüber dem Standard geändert? Werden sie von mehreren Personen gemeinsam genutzt, was eine Zuordnung unmöglich macht? Wird die Zahl der Versuche begrenzt? Ein Tester prüft zusätzlich, ob Basic Authentication neben einem modernen Anmeldeablauf besteht: eine Anwendung mit ordentlicher Anmeldeseite und daneben einer API oder einem Verwaltungspfad mit Basic ist ein häufiges Muster, bei dem dieser zweite Weg den zweiten Faktor umgeht. AssistSec beurteilt, ob der Einsatz für die jeweilige Anwendung vertretbar ist, denn eine interne Anbindung über TLS ist etwas anderes als eine Verwaltungsoberfläche für Personen.

Wie verhindert man Basic Authentication?

• Ersetzen Sie Basic Authentication für Nutzer durch einen Anmeldeablauf mit Sitzungsverwaltung und Cookies.
• Erzwingen Sie TLS, solange das Verfahren noch im Einsatz ist, und sperren Sie jede unverschlüsselte Route.
• Verwenden Sie für maschinelle Anbindungen ein Token oder einen API-Schlüssel, den Sie rotieren können.
• Ändern Sie Standardzugangsdaten und verwenden Sie nie gemeinsame Konten für Personen.
• Sorgen Sie dafür, dass ein zweiter Faktor möglich ist; das erfordert fast immer ein anderes Verfahren.
• Filtern Sie den Authorization-Header aus Protokolldateien, Überwachung und Fehlerberichten.
• Begrenzen Sie die Zahl der Anmeldeversuche, auch bei einem Verfahren, das je Anfrage authentifiziert.
• Prüfen Sie, ob neben Ihrem modernen Anmeldeablauf kein zweiter Kanal mit Basic besteht.
• Schirmen Sie Verwaltungsoberflächen auf Netzwerkebene ab statt allein mit einem Passwort.