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.
Ich finde es richtig, 2FA verpflichtend zu machen.
Leider spielt die 2FA nicht direkt mit der in GitLab zusammen, um die 2FA-Notwendigkeit auf dessen Berechtigungsebene zu konfigurieren.
Aber: Wenn TOTP verwendet wird, sollte man schon Backup-Codes anbieten. Wer z.B. sein Mobile verliert (oder kein Backup der Schlüssel in der TOTP-App hat), sollte eine Login-Möglichkeit per einmaligem Backup-Code bekommen. Sonst steigt der Support-Aufwand.
Aus diesem Grund, speichere ich meine 2FA keys im Keepass in einem Keyfile auf dem persönlichen Netzlaufwerk Da hab ich auch nach Verlust des Gerätes weiter Zugriff drauf!
Also Keycloak und 2FA schließen sich überhaupt nicht aus.
Nur weil du ein SSO hast, heißt das nicht das dein 2FA überflüssig wird (wieso sollte er?), im Gegenteil ich halte ihn dann sogar für noch wichtiger.
Ein SSO zentralisiert den Login, d. h. sehr banal gesagt, ein erfolgreicher Angriff auf das SSO-System (z. B. Keycloak) würde allen verbundenen Dienste* (GitLab, Nextcloud, etc.) den Zugriff ermöglichen und wenn man dann dein Passwort hätte (jetzt hoffentlich nicht durch einen Angriff auf Keylcoak, weil dann gäbe es andere Probleme), dann könnte man einfach Zugriff erhalten und zwar auf alle verbundenen Dienste. Das wäre ein Super-GAU.
Deshalb hast du die 2FA, dass selbst wenn wer das Passwort haben sollte, dass der da nicht einfach reinkommt und GERADE weil da ein SSO hinter hängt.
Dann kommen da bestimmt noch 27001 Regeln dazu, dass du das als Admin für den Zugriffsschutz brauchst. Aber das einfach mal generell als Erklärung, dass es nicht entweder oder ist, sondern ein „und“ und das auch so ganz richtig gelöst wurde (jedenfalls sicherheitstechnisch).
Ist die Frage ob es weil es technisch möglich ist in der öffentlichen Verwaltung (mal abgesehen von Forschungseinrichtungen und anderen „higher risk“ Fällen) wirklich immer notwendig ist 2FA zusätzlich zu nutzen.
Hängt vermutlich von der individuellen Risikoanalyse ab.
Das vermeidet bei „low risk“ Fällen 2FA-Fatigue (Zu häufige 2FA-Aufforderungen können Nutzer frustrieren) und reduziert den Maintenance-Overhead (2FA Nutzer-, Gruppen-, … Verwaltung) → Kosten signifikant. Bitte nicht falsch verstehen, in der öffentlichen Verwaltung obligatorisch 2FA zu fordern halte ich für unrealistisch/realitätsfremd (ich habe Bekannte, die von ähnlichen Zuständen berichten können):
Im Fall von OpenCode schließt man somit viele Nutzer aus, die die Plattform nutzen können sollten. Das ergibt für mich im Großen und Ganzen wenig Sinn.
Zusammenfassend finde ich es übertrieben und zu exklusiv für OpenCode für alle Nutzer 2FA zu fordern. Ich stimme dem schon genannten Vorschlag zu:
Ja, Ja und nochmal Ja. Du solltest auch als Privatperson 2FA nutzen.
Ich versuche jetzt sehr neutral darauf zu antworten. Auch wenn ich ehrlich gesagt etwas genervt bin, weil ich jetzt zwei Beiträge gesehen habe und beide haben sehr starke KI-Nutzung gehabt und ich lese das auch bei diesem heraus. Das sagt mir entweder das sehr viel Meinung direkt von der KI einfach übernommen wird und/oder hinter dem Post ein noch sehr unerfahrener Mensch in der IT steckt, der auch nicht versteht, was er mit solchen Aussagen dann im Zweifel anrichtet und ja mir ist klar, man möchte was schlaues sagen usw.
Dein Beitrag sagt im Endeffekt, dass man Sicherheit runterschrauben soll, gerade bei den Menschen, die das größte Sicherheitsrisiko sind, weil sie es ermüdend finden. Was ist das für eine Aussage? Das ist der Grund, bzw. einer, warum wir so oft in Deutschland angegriffen werden, weil wir unsere Sicherheit zurückschrauben statt sie zu verbessern.
Früher war es z. B. normal das man sich ein Passwort merkt oder nutzt (was auch gut ist und heute nicht mehr immer ausreichend), so aber für viele Menschen z. B. bei einer Flugbuchung oder bei Bonus-Programmen war das jetzt plötzlich zu schwer und man muss sich nur noch an Nachnamen und Postleitzahl erinnern, weil es mehr „convience“ für diese Menschen hat. Folge waren zahlreiche Hacks.
Das wird auch alles schlimmer statt besser (Quantencomputer, KI usw.) und da immer wieder die Sicherheit runter zu schrauben, statt hoch und die Menschen, dann mal richtig zu schulen und mitzunehmen macht es nicht besser. Dazu ist der Beitrag auch alles reine Meinung und Gefühl.
Es gibt tatsächlich technische Standards, die einzuhalten sind (NIS2, DSGVO/TOMS, ISO27001).
Ein Beispiel hier:
Das BSI empfiehlt den Verbraucherinnen und Verbrauchern für eine sichere Anmeldung bei Onlinediensten die Zwei-Faktor-Authentisierung (2FA)
Das BSI empfiehlt die Nutzung der 2-Faktor-Authentisierung, wo immer dies möglich ist.
Ein Passwort ist grundsätzlich geeignet sich an einem System zu authentifizieren + Alleinige Passwörter sind zu unsicher.
Okay, dann lass mal das Risiko für Developer durchgehen. Du kannst dich damit auf den Gitlab anmelden. Ohne zwei Faktor, das heißt du kannst dann Code pushen.
Die haben das extra soweit eingedämmt, dass hier „unberechtigte“ keinen Code pushen oder bearbeiten können.
Was kann passieren? Man könnte z. B. Schadcode pushen und die Awareness dafür wäre vielleicht nicht sofort gegeben, weil es von einem behördlichen offiziellen Konto kommt, dass dafür auch speziell freigeschaltet wurde. Man hätte vielleicht auch auf private Repositories Zugriff, die nicht für die Öffentlichkeit gedacht sind.
Desweiteren werden hier ja auch Konten auch nicht wirklich gelöscht, jedenfalls sehe ich ein 3 Jahre inaktives Konto (Datenminimalismus).
So und was ist, wenn da wer das Passwort hat? Ist wie überall, man kann dann Nachrichten, Namen usw. sehr einfach einsehen. Entweder man löscht es nach einiger Zeit oder man hat besser einen 2FA (oder am besten beides).
Und mit einer gewissen Stufe im Forum kann man auch etwas mehr löschen, ändern usw. und da auch gut Schabernack treiben ohne das man das sofort mitbekommt.
Du kannst das ja fordern, aber es ist wie gesagt nur ein Gefühl. Die gesetzlichen Regelungen sind anders und das aus sehr guten Gründen, die durchaus sehr sinnvoll sind.
Ja gute Punkte. Dann wäre folgendes vermutlich ein plausibler Mittelweg:
2FA für Owner, Maintainer und Developer (mit Admin + Schreibrechten) verpflichtend.
Kein 2FA für Guests (ohne Admin + Schreibrechte). → Ermöglicht potenziellen Nutzern „barrierefreien“ Zugang ohne ein Risiko darzustellen.
—-
Beruflich und privat nutze ich immer MFA. Es geht hier primär um einen inklusiven Zugang für weniger IT affine Nutzer („Multiplikatoren“ und „Beauftrager“). Sonst wir OpenCode immer in unserer Nerd-Bubble bleiben und weniger genutzt und/oder langsamer etabliert.
und siehe oben Erklärung zur DSGVO, NIS2…
Es ist mir schleierhaft wie man bei den gesetzlichen Vorgaben plötzlich zu einem Mittelweg kommt. Die müssen auch alle mit 2-Faktor mindestens beim Onlinebanking klar kommen oder bei Elster oder bei E-Mail…
Das hat nichts mit „barrierefrei“ zu tun. Wie gesagt die Accounts werden nicht automatisch gelöscht, das ist auf Dauer ein Problem und sicherheitshalber nochmal: Es gibt gesetzliche technische Standards für solche Dinge.
Wenn man pauschal sagt, 2FA sei „nicht barrierefrei“, dann ist das zu kurz gegriffen. Bei barrierefreiheit gehts darum inklusive Lösungen anzubieten, nicht, Sicherheitsfeatures abzuschaffen. Man könnte stattdessen Biometrie nutzen, aber dann hat man ein Datenschutzproblem und auch hier Einschränkungen. Es gibt auch Hardware Tokens mit Signaltönen etc. für Blinde genau für solche Zwecke oder oder oder…
Aber die Diskussion ist um 2-FA und der ist notwendig.
Technologische gesehen wird es vermutlich nie eine 100% sichere Option geben. Und eine Verfügbarkeit von Devices für MFA in der öffentlichen Verwaltung… eher auch nicht flächendeckend fürchte ich.
Die Manipulation von Daten zu verhindern (Role Based Access Control → principle of least privilege) hilft schon ungemein und wird vermutlich sowieso schon berücksichtigt.
Da hab ich auch nach Verlust des Gerätes weiter Zugriff drauf!