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).