Authentication Methods
Methoden zur Authentifizierung

MFA – Mehr Freude am Authentifizieren oder Möglichst Fehlerhafte Authentifizierung?

von

Nachdem ich in kurzer Zeit über zwei sehr unterschiedliche Blogeinträge zu MFA gestoßen bin und diese auf dem ersten Blick widersprüchlich waren, habe ich mich etwas mehr damit beschäftigt.

Im Blog von Daniel Miessler findet sich eine Übersicht zu verschiedenen MFA-Verfahren, als Erweiterung eines Beitrages zum Consumer Authentication Strength Maturity Model (CASMM).

Im Detail kann man sicherlich anderer Meinung sein, aber ich finde diesen Ansatz sehr hilfreich. Auch die vorgeschlagene Anpassung auf das jeweilige Bedrohungsmodell ist nicht zu unterschätzen.

Die Nutzung von SMS auf Level 5 könnte eine Absenkung des Sicherheitsniveaus bedeuten kann, wenn man dafür schwächere Passwörter einsetzt oder sorgloser mit ihnen umgeht. Das ist mir so leider schon einmal untergekommen. Dass SMS eine schlechte Option sind wurde oft genug auf dem Chaos Communication Congress gezeigt. Trotzdem bieten mir selbst Banken diese noch immer in verschiedenen Szenarien an.

Zwischen Level 6 (App-based 2FA Codes – nach meinem Verständnis bspw. TOTP) und Level 7 (App-based Codeless 2FA) schwanke ich häufig. Level 7 ist meist auch bequemer, aber gefühlt bin ich eher der Level 6 Typ 😉. Vor allem wenn mehr als ein Gerät aktiviert wurde oder diese nicht beschränkt werden können, bin ich skeptisch. Andererseits ist in diesen Fällen die Kontrolle der Menge der zulässigen Geräte oft einfacher, bzw. überhaupt erst möglich. Das ist bei TOTP nur möglich, wenn die QR-Codes über die gesamte Lebenszeit geschützt sind, aber wenn das nicht der Fall ist, habe ich außer der Benachrichtigung über eine Anmeldung an einem Dienst keine Möglichkeit mehr das festzustellen. Schwierig. Meist hat man pro Dienst auch keine Option und dann muss man es auch nicht vertiefen.

Ich habe die Möglichkeit zum Backup von TOTP ehrlich gesagt erst durch die Folge Zwei-Faktor-Authentifizierung des INNOQ Security Postcasts auf dem Schirm gehabt. Davor habe ich bei einem defekten Gerät die verschiedenen Wiederherstellungsoptionen (Einmal-Codes, zweite E-Mail-Adresse und auch SMS) genutzt, um meine TOTP im Google Authenticator wieder zum Fliegen zu bringen. Ein Dienst war damals nicht trivial wiederherzustellen: Für Bitcoin.de war es zum Glück möglich das alte Smartphone kurzzeitig wieder funktional zu machen (beim Samsung Galaxy Note 4 hilft es bei der Fehlermeldung „ddi mmc_read failed“ wirklich das Gerät im Kühlschrank vor dem Boot zu kühlen). Ansonsten wäre es aufwändiger geworden. Daraufhin hatte ich für eine Weile Abstand von TOTP genommen. Dank der Episode im Podcast habe ich eine Sicherung und nutze TOTP nun für viele weitere Dienste. Vor kurzen lief auch der Recovery-Test erfolgreich.

Bei der Umstellung und Erstellung der Sicherung habe ich mich bei vielen Diensten nach Alternativen umgesehen und bin noch viel zu oft über die SMS als einzige Option gestolpert. Selbst wenn diese nicht die primäre Option ist, bringt sie als aktivierte Fallback-Option ihre Schwäche voll ein. Sehr häufig begegnet mir auch die E-Mail als Alternative zur SMS. Das ist zumindest ein kleiner Fortschritt (in einem Fall sogar mit PGP), aber meist nicht der große Wurf. Auch habe ich schon öfter erlebt, dass die E-Mail länger unterwegs war, als der Code gültig gewesen wäre.

Gerne wäre ich großflächig auf FIDO2 umgestiegen, aber es gab wirklich nur eine kleine Menge von Diensten, die das überhaupt anbieten – vielleicht mache ich auch nur die falschen Dinge im Internet. Für die Begeisterung die FIDO2 ausgelöste, als ich davon zuerst hörte, empfinde ich das als sehr enttäuschend.

Im Prinzip finde ich die Idee von FIDO2 direkt im Betriebssystem charmant, auch wenn ich eine zweite dedizierte Hardware deutlich bevorzuge. Bei vielen Diensten wäre eine Verankerung der Authentifizierung im OS aber besser als Benutzername/Passwort. Meistens reicht die Ablage eines simplen Accounts in meinen KeePassXC aber auch aus. Bei einigen Konten mit FIDO2 finde ich die entsprechenden Anmelde-Optionen zu gut versteckt.

Laut Kommentaren zum CASSM ist U2F ebenfalls der obersten Schicht (Passwordless) zugeordnet. In vielen Implementierungen ist dies für mich kein richtiges MULTI-Faktor, da das Passwort entfällt – abgesehen vom PIN für den Hardware-Token. Rein technisch finde ich FIDO2 einfach eine elegantere Lösung. Am Ende sind wohl aber die Eigenheiten der Implementierungen durch die nutzenden Services fast ausschlaggebender für die Nutzbarkeit und die Sicherheit.

Dass MFA nicht der heilige Gral der Authentifizierung ist und selbst Level 7 seine Schwächen hat, ist mir durch die Angriffe von Lapsus$ erst richtig bewusst geworden (zumindest klingt es in der Berichterstattung nach Level 7). Klar wurden zuvor häufig vorhandene Schwächen aufgezeigt, aber durch einen Blog-Beitrag von Bruce Schneier bin ich auf einen Beitrag auf Ars Technica gestoßen, der das MFA Bombing gut veranschaulicht: “Call the employee 100 times at 1 am while he is trying to sleep, and he will more than likely accept it. Once the employee accepts the initial call, you can access the MFA enrollment portal and enroll another device.” Also eins muss ich Lapsus$ trotzdem lassen, ich bin als Teenager nicht auf solche Ideen gekommen.

Dass solche Versuche nicht in der Evaluierung von Logeinträgen (bspw. durch ein SIEM) auffallen, ist meines Erachtens ein Fax Pas – zumindest, wenn die Versuche wirklich so brachial waren, wie es sich liest. Mit dezentem, aber kontinuierlichen Versuchen hängt es auch wieder an der Awareness der Mitarbeiter und ob diese fehlerhaften Anfragen auch melden. Ob diese dann auch als Security Incident richtig erkannt und behandelt werden ist eine weitere Fehlerquelle, die viel Spielraum für Fehler öffnet.

Nichtsdestotrotz ist MFA Bombing je nach Bauart auf Basis von Social Engineering oder Brute Force eine Bedrohung, welche ich in Zukunft berücksichtigen möchte.

MFA ist also nur im Verbund mit anderen flankierenden Maßnahmen sicher und das Zusammenspiel funktioniert wohl nur selten out-of-the-box und ist ein wichtiger Lernprozess.

So ein bisschen habe ich hier die Problemstellungen aus dem privaten und dem Enterprise Umfeld vermengt. In beiden Fällen sind jedoch gewachsene Umgebungen verbunden mit suboptimaler Priorisierung anzutreffen und machen einen großen Teil des Problems aus. Ich bin aber zuversichtlich, dass es noch Verbesserungen in der Zukunft geben wird.

Auch die technische Basis für meinen Blog ist ein gutes Beispiel für die Probleme. Dank der geringen Zahl an Accounts und Rollen kann ich mich über jede erfolgreiche und erfolglose Anmeldung informieren lassen und alles manuell auswerten (das ist nicht als Herausforderung zu verstehen). Ich hätte gerne FIDO2 genutzt, aber im gesamten Zusammenspiel schien TOTP am praktikabelsten und zuverlässigsten.

Generell wäre ein zentraler Authentifizierungs-Provider für viele Seiten schon ein bisschen cool, aber meist trifft man hierzu nur Dienste von Google und Facebook an und diese sind mir an dieser Stelle suspekt und keine Option. Und da es aktuell keine flächendeckenden Alternativen gibt, brauche ich mir über die weiteren Nachteile einer zentralen Lösung auch keine Gedanken machen. Das ist im Enterprise-Umfeld schon deutlich einfacher.

Quellen: