wir sind hier etwas irritiert über die verpflichtende 2FA auf der Plattform.
So ist es doch aus unserer langjährigen Erfahrung absolut unüblich in OS-Communities mit einer 2-Faktor-Authentifizierung zu arbeiten geschweige denn dies zur Voraussetzung zur Nutzung der Kollaborationsplattform zu machen.
Insbesondere im dienstlichen Kontext ist die Verfügbarkeit von Smartphones für eine App nicht flächenhaft gegeben. Die Nutzung privater Geräte für dienstliches großteils nicht gewollt und z.t. auch untersagt.
Aus unserer Sicht wäre die 2FA als optionale Möglichkeit auf Projektebene und die so erreichte Senkung der Einstiegshürde auf die Plattform hilfreich, um eine Nutzung in der Breite zu fördern.
Insofern wir produktive Umgebung und Open-Source-Projekt einheitlich verwenden wollen finde ich persönlich den Einsatz von 2FA sinnvoll und wir würden das bei einer selbst betriebenen GitLab-Instanz wohl auch fordern.
Andererseits sehe ich natürlich das Problem für die Kollaboration gerade mit Personen die nicht beruflich in die Projekte integriert sind. Hier sind alle zusätzlichen Hürden (z.B. auch überhaupt noch einen Account auf OpenCoDE anzulegen anstatt bestehende auf GitHub oder GitLab zu nutzen) problematisch weil vor allem „drive-by contributions“ unwahrscheinlicher werden.
Idealerweise würde ich mir eine Verbindung mit der Nutzerverwaltung von GitLab selbst wünschen, z.B. 2FA für Owner und Maintainer verpflichtend, aber für Developer und Guest nicht. Oder über die Gruppen- und Projekt-Konfiguration festlegen ob 2FA für den Einsatzzweck notwendig ist oder nicht. Aber ich vermute, dass sich daraus einerseits technische Probleme in der Integration mit Keycloak und andererseits Schwierigkeiten für das Sicherheitskonzept von OpenCoDE ergeben würden.
Abschließend würde ich noch erwähnen, dass ich private mobile Endgeräte im dienstlichen Umfeld ebenfalls als hochgradig problematisch empfinde. Allerdings gibt es durchaus Alternativen wie Hardware-basierte TOTP wie z.B. Nitrokey die ich den selbst relativ anfälligen Smartphones sogar vorziehen würde oder als Übergangslösung kann KeePass(X(C)) ebenfalls TOTP erzeugen auch wenn man dann keinen wirklich unabhängigen zweiten Faktor mehr hat.
Der Einsatz von 2FA ist für jeden Account sinnvoll.
Des Weiteren ist für den Einsatz auf dieser Plattform überhaupt keine Smartphone App notwendig.
Einen TOTP bekommt man auch mit den meisten gängigen Passwort-Managern, wie beispielsweise KeePassXC - ohne App, ohne Google, Open Source.
bei Github ist 2FA ebenfalls verpflichtend und aus Sicherheits-Sicht absolut notwendig.
Am RKI verwenden wir wie genannt KeePassXC für Passwort und 2FA.
2FA via KeePass ist nicht zu empfehlen, da hiermit der eigentliche Schutz degradiert wird. Es handelt sich damit nicht länger um ein echtes 2FA, denn dafür ist ein getrenntes Gerät unabdingbar. Es ist wirklich wichtig zu verstehen, dass dies ähnlich unsicher ist, wie zwei getrennte Passwörter zu verwenden und damit falsche Sicherheit suggeriert wird.
Meine persönliche Empfehlung sind U2F Keys, z.B. Yubi Keys, diese sind einfach in der Verwendung und darüber hinaus auch noch sicherer als TOTP.
Bei Nutzung auf dem selben Gerät stmme ich zu. Ist das gleiche Prinzip, wie wenn man SMS via Smartphone empfängt und den Code dort dann in eine App/in den Browser eintippt. Generell ist aber nichts am Faktor bzw. der Berechnung von KeepassXC auszusetzen. Hab das auf unterschiedlichen Geräten, in einer anderen ArbeitVM oder ähnliches und good2go. Allerdings, wenn es soweit ist, dass jemand auf deinem lokalen Rechner, dein KeepassXC auslesen kann, dann hast du ganz andere Probleme als nur dein OTP.
Bei Yubikey als auch Nitrokey hast du eine höhere Sicherheit, allerdings werden die nicht wirklich (nicht mal im Informatikbereich angenommen). Dafür sind die noch zu teuer, ich kenne auch keinen Laden wo du Notfalls schnell jetzt sofort Ersatz bekommst, wenn es denn mal brennt. Das macht das alles schwieriger.