Two Factor Authentication (2FA)

[jd7]

Hallo zusammen,

ich nutze OPNsense schon seit einigen Jahren und schätze die integrierte 2FA sehr. Allerdings empfinde ich das Anfügen des OTP-Tokens an das Passwortfeld in der Praxis als etwas umständlich.

Ich habe mir daher Gedanken über ein zusätzliches, eigenes Eingabefeld für den 2FA-Code auf der Login-Seite gemacht.

Damit das Ganze Hand und Fuß hat, habe ich dafür eine Sicherheits- und Risikoanalyse (TARA) durchgeführt. Der Vorteil einer solchen systematischen Überprüfung ist, dass dabei nicht nur das neue UI-Feld betrachtet wird, sondern auch direkte Sicherheitsgewinne für die gesamte Log-in-Logik abfallen:

* Schutz vor Timing-Angriffen: Die Antwortzeiten verraten nicht mehr, ob ein Benutzer existiert oder ob 2FA aktiv ist.
* DDoS-Schutz fürs WebUI: Blockaden (Rate Limiting) greifen, bevor rechenintensive Passwort-Prüfungen das System belasten.
* Keine Token-Wiederverwendung: Bereits genutzte OTP-Codes werden sofort für die weitere Verwendung gesperrt.
* Saubere Log-Einträge & Absicherung: Besserer Schutz gegen Log-Fälschungen und fehlerhafte Fehleingaben.

Im Anhang findet ihr die TARA-Analyse sowie einen beispielhaften PHP-Code-Prototypen.

Wie seht ihr das? Wäre ein separates Feld inkl. dieser Backend-Anpassungen aus eurer Sicht ein Mehrwert oder eher unnötiger Aufwand für die Entwicklung?

Ich freue mich auf euer Feedback!

Viele Grüße
jd

[meyergru]

https://github.com/opnsense/core/issues/8239

https://github.com/opnsense/plugins/issues/5592

[jd7]

Hallo meyergru,

danke für die Links, die Tickets kannte ich noch nicht!

Mir geht es hier allerdings weniger um das UI, sondern primär um die Backend-Härtung aus der TARA-Analyse:

- Timing-Schutz gegen User-Enumeration
- DoS-Schutz durch frühes Rate-Limiting
- Replay-Schutz für benutzte TOTPs

Das UI-Feld ist nur die logische Folge der überarbeiteten Backend-Logik.

Da das Thema in den alten Tickets bisher nicht umgesetzt wurde: Besteht an einer solchen Backend-Härtung überhaupt Interesse, und ist eine Unterstützung hier gewünscht?


Vg
Jd7

[Monviech (Cedrik)]

Soweit ich weiß gibt es bereits:

- Timing schutz (alle logins brauchen die selbe Zeit)
- DoS Schutz (zu viele falsche Logins lassen eine IP auf die Virusprod Firewall Alias wandern, sie werden dadurch gesperrt)
- Replay Schutz kann ich nicht einschätzen, der TOTP token ist nur 30 sekunden oder 1 Minute gültig. Wenn jemand alle Faktoren und sie replayen kann ist das OS kompromittiert oder es gibt andere Vertrauensprobleme. Der Standard basiert halt auf Zeit.

Falls ein echtes nachvollziehbares Problem gefunden wird bitte auf Github eine issue oder einen Security Report öffnen.

[meyergru]

Ich schickte die Tickets wegen der darin enthaltenen Diskussionen und den darin enthaltenen Punkten, die Deine Analyse noch nicht enthält.

Der primäre Grund für das Auseinanderziehen der Eingabefelder wäre a.m.S. die Möglichkeit, das standardkonform mit Passwort-Managern machen zu können. Es wurde dagegen ins Feld geführt, dass man, wenn das in Abhängigkeit von 2FA ein/aus gemacht wird oder sogar, wenn man das Feld immer mit anzeigt, man auf die OpnSense-Version rückschließen kann.

Das ist im ersten Fall richtig, im zweiten falsch bzw. irrelevant, weil man aufgrund der JS/CSS-Dateien sowieso den Versionsstand profilen kann, also ist das kein Argument dafür oder dagegen.

Was die Replay-Attacken angeht, bin ich unschlüssig. TOTP ist inhärent kein Mechanismus, der dagegen schützt, was einer der Gründe ist, wieso es für PSD2 nicht zugelassen ist. Man könnte das zusätzlich einbauen, um gegen Man-In-The-Middle-Attacken zu schützen, die den Login abgreifen und zeitnah ein zweites Token holen.

Ich würde sagen, dass benutzerselektives TOTP das Verfahren als solches unterläuft. Ganz oder gar nicht.

Die anderen Hinzufügungen sind m.E. auch sinnvoll, allerdings muss man sagen, dass der Komfort bei allen diesen Dingen leidet. Nimm als Beispiel das Verstecken des Grundes für das Misslingen: Da könnte sich ein User aussperren, weil die Uhrzeit auf der OpnSense nicht stimmt.

Man müsste hier streng darauf achten, dass der Grund für die Ablehnung quasi nie offengelegt wird. Es wurde ja auch diskutiert, dass man das TOTP-Feld erst nach korrekter Passwort-Eingabe anzeigt - geht aus genau dem Grund nicht. Andererseits würde das Hinzufügen des Eingabefelds viele User verunsichern...

Mein Eindruck war, dass das ganze Thema bei Deciso insgesamt nicht auf großes Interesse stößt... es gab schon mal Patches, die aber nicht berücksichtigt wurden (ich kenne aber die konkreten Gründe nicht).

[jd7]

Hallo Monviech, hallo meyergru,

danke euch für die Rückmeldungen und den Input aus den GitHub-Tickets! Ich möchte gerne auf eure Punkte eingehen und erklären, warum ich mich im Rahmen der TARA-Analyse (Threat Analysis and Risk Assessment) klar für ein einziges Formular mit separaten Feldern (Username, Passwort, OTP/TOTP) und gegen ein zweistufiges Verfahren (Two-Step Login) ausspreche:

1. Ein Formular (Combined Form) vs. Zwei Formulare (Two-Step Login)

Ein zweistufiges Verfahren (erst User/Passwort, danach bei Erfolg OTP-Abfrage) birgt im Sicherheitskontext gravierende Nachteile:

- Sicherheitsrisiko "State-Handling": Sobald nach Schritt 1 das OTP abgefragt wird, muss der Server im Backend einen "Teil-Authentifizierungs-State" (z. B. via Session/Token) verwalten. Das schafft eine Angriffsfläche für Session-Hijacking oder State-Bypassing, bevor die eigentliche 2FA überhaupt vollständig abgeschlossen ist.

- Information Leakage / User Enumeration: Wenn erst nach richtiger Passwort-Eingabe das OTP-Feld erscheint, erfährt ein Angreifer sofort, dass das Passwort korrekt war. Bei einem einzigen Formular schlagen falsches Passwort, falscher TOTP-Code oder ein fehlender Code immer in demselben "Invalid credentials"-Fehler fehl.

- Gleicher Schutz ohne UX-Bruch: Wenn das OTP-Feld immer präsent ist (oder optional per UI eingeblendet werden kann, ohne Rückmeldung über Passwort-Gültigkeit zu geben), gibt es keinerlei Information Leakage über den Validierungsstatus des ersten Faktors.

2. "Bisher keine Angriffe beobachtet" ist kein Sicherheitsargument

Dass gewisse Angriffe auf OPNsense-Instanzen bisher vielleicht nicht prominent beobachtet wurden, ist kein Beleg für deren Abwesenheit oder eine Entwarnung für die Zukunft:

- Der Markt verändert sich drastisch: Derzeit sehen wir eine massive Welle von automatisierten, hochskalierten Angriffen auf kommerzielle Firewall- und VPN-Lösungen (Cisco, Fortinet, Ivanti etc.). Da Open-Source-Lösungen wie OPNsense im Enterprise-Umfeld immer beliebter werden, rücken sie automatisch stärker in den Fokus professioneller Angreifer.

- Timing-Attacks & Enumeration sind Standard: Automatisierte Botnets testen heute routinemäßig auf Timing-Unterschiede und Enumeration-Lücken, um gültige Konten vorab zu filtern, bevor der eigentliche Brute-Force-Angriff startet.

3. Zu den drei spezifischen Backend-Punkten

- Timing-Schutz (User Enumeration): Ein generisches sleep reicht oft nicht aus, wenn der Pfad für "User existiert nicht" signifikant schneller fehlschlägt als "User existiert, aber Passwort falsch" (z. B. wegen des kryptografischen Hashing-Oversize bei BCPrypt/Argon2). Hier ist ein konstanter Laufzeit-Pfad im Backend essenziell.

- DoS / Rate-Limiting: Die Einbindung ins Firewall-Alias (z. B. via sshguard / blocklist) ist super, greift aber oft erst nach N Fehlversuchen auf IP-Ebene. Ein frühes Rate-Limiting direkt auf Applikationsebene schützt das Backend davor, dass teure Hash-Funktionen die CPU der Firewall lahmlegen.

- Replay-Schutz für TOTP: Da TOTP-Tokens innerhalb ihres 30-Sekunden-Fensters mathematisch valide bleiben, sind sie anfällig für kurzfristige Replay-Angriffe (z. B. abgefangen via Man-in-the-Middle / Phishing-Proxies wie Evilginx). Ein einfaches Cache-Register im Backend, das bereits verwendete TOTP-Tokens für deren Gültigkeitsdauer speichert und ein zweites Mal ablehnt, eliminiert diese Lücke vollständig – unabhängig vom Betriebssystem-Zustand.

Mir geht es absolut nicht darum, das System unnötig zu verkomplizieren oder den Komfort einzuschränken. Die Implementierung einer sauberen Backend-Logik mit einem integrierten OTP-Feld verbessert sowohl die UX (Passwort-Manager Support) als auch die Härtung gegen moderne Angriffsmuster massiv.

VG
jd

[meyergru]

@jd7: Mich musst Du nicht überzeugen. Ich bin klar für ein TOTP-Feld, dass immer angezeigt wird (aber bei nicht aktiver TOTP nicht gefüllt werden muss). Alle anderen Dinge - richtig implementiert - sind sicherheitstechnisch sinnvoll.

Auf der anderen Seite glaube ich, dass die Fehlermeldungen alle Möglichkeiten beinhalten sollten, ohne die spezifische Ursache (User nicht vorhanden / Passwort falsch / OTP (oder Uhrzeit) falsch / DoS erkannt) zu benennen. Aus Abwägung bzgl. Useability würde ich eventuell sogar die Uhrzeit und das Datum in der Fehlermeldung anzeigen. Und selbst dann würden nach Einführung der Änderung Diskussionen und "dumme" Fragen hier im Forum die Folge sein.

Und wie gesagt: AFAIK, geht im Augenblick nur TOTP für alle oder für keinen - das würde ich so belassen. OWASP empfiehlt MFA für alle Benutzer und ausdrücklich verpflichtend für administrative bzw. privilegierte Accounts. Ja - man könnte für weniger priviligierte Accounts auch TOTP-freien Zugang erlauben, nur ist die Realität, dass das Anwender genau nutzen würden, um einen "Reserve"-Root-Account zu haben, der auch bei falscher Uhreinstellung den Login garantiert.

Beiseite gesprochen sollte der Admin-Zugang firewalltechnisch sowieso nur von vertrauenswürdigen Quellen aus zugänglich sein. Echte Angriffsszenarien sind also hoffentlich eher selten.

[Monviech (Cedrik)]

Irgendwie fühlt sich der Thread wie eine LLM Diskussion an. Sorry aber ich bin raus xD

[jd7]

@Monvievh: Sorry, mache das beruflich ;-). Nur statt IT im Bereich Automotive mit Automobilhersteller und -zulieferer.