2FA-Pflicht bei GitHub: Interview mit Sicherheitschef Mike Hanley
Zwei-Faktor-Authentifizierung ist der erste Schritt, um Online-Identitäten zu schützen. GitHub hat sich entschieden, den zweiten Faktor zur Pflicht zu machen.
(Bild: Sundry Photography/Shutterstock.com)
Attacken auf Softwarelieferketten haben in den letzten Jahren zugenommen. Für Angreifer ist es besonders attraktiv, Schadcode in Software-Bibliotheken einzuschleusen, die von vielen anderen Projekten genutzt werden. Die Codehosting-Plattform GitHub will im Lauf des Jahres alle Nutzer, die Code beitragen, dazu verpflichten, ihren Login mit einem zweiten Faktor wie einem Einmalpasswort aus einer App abzusichern (2FA). In mehreren Blogbeiträgen hat GitHub die Änderung angekündigt. Seit dem 13. März erhalten erste Nutzer die Aufforderung, umzustellen. Mit Mike Hanley, Chief Security Officer und Senior Vice President bei GitHub, hat c't über die Umstellung gesprochen.
c’t: GitHub macht Zwei-Faktor-Authentifizierung seit März sukzessive zur Pflicht. Bis zum Jahresende soll der Prozess abgeschlossen sein. Wie hat das angefangen?
Mike Hanley: Es hat angefangen im November 2021. In der npm-Registry, die GitHub gehört, gab es einige Fälle von Protestware (Anmerkung: Entwickler, die eigene Repositories aus Protest offline nehmen oder sabotieren) und der Account eines Maintainers von einem beliebten Paket wurde übernommen. Der Angreifer konnte dadurch Schadcode verteilen. Das ist ein attraktiver Angriffsvektor, denn so kann Schadcode schnell 10.000 bis 100.000 Mal heruntergeladen werden, selbst wenn das Problem schnell beseitigt wird. Als Reaktion haben wir die Zwei-Faktor-Authentifizierung kurz danach verpflichtend in npm gemacht. Dabei haben wir viel gelernt und wollen jetzt die gleiche Nutzererfahrung auf GitHub.com anbieten.
c’t: GitHub hat über 100 Millionen Nutzer. Ist nicht zu erwarten, dass die durch die Umstellung in ihrer Arbeit behindert werden?
Hanley: Wir haben die 2FA-Pflicht für Nutzer, die Code auf GitHub.com beitragen, ungefähr ein Jahr im Voraus angekündigt, damit Unternehmen und die Open-Source-Community vorbereitet sind. Ende vergangenen Jahres haben wir den März als geplantes Startdatum kommuniziert. Seit dem 13. März teilen wir die Nutzer in Gruppen ein, die einen zweiten Faktor zum Login brauchen. Viele Nutzer in der ersten Kohorte hatten 2FA übrigens schon aktiviert. Es gibt außerdem eine großzügige Frist von 45 Tagen, nachdem man benachrichtigt wurde, die sich auch nochmal um eine Woche verlängern lässt. Wenn man sich danach auf GitHub.com anmeldet, muss man einen zweiten Faktor wie SMS oder TOTP (Time-based One-time Password) einrichten oder GitHub Mobile nutzen. Wir empfehlen Sicherheitsschlüssel für das WebAuthn-Protokoll. Die sind die sicherste Authentifizierungsmethode, die aktuell zur Verfügung steht.
(Bild: github.blog)
c’t: Aber auf solche Sicherheitsschlüssel hat nicht jeder Zugriff. Ein FIDO2-Schlüssel kostet um die 50 Euro.
Hanley: Ja, die sind nicht günstig. Wir wollen gewährleisten, dass es sichere Methoden zur Authentifizierung gibt und trotzdem niemanden ausschließen. Deswegen erlauben wir auch SMS als zweiten Faktor, obwohl die Variante weniger sicher ist als andere. Man muss einen Kompromiss eingehen, damit Leute sich weiter an Projekten beteiligen können. Aber möglicherweise versuchen wir, die Nutzer irgendwann zu sichereren Authentifizierungsmethoden zu bewegen.
c’t: Wie soll das aussehen?
Hanley: Schon heute zeigen wir Nutzern in regelmäßigen Abständen an, welche Methoden zur Zwei-Faktor-Authentifizierung sie aktiviert haben, ob sie ihre Backup-Codes ausgedruckt haben und fragen nach, ob all diese Mechanismen so noch aktuell sind. Das ließe sich leicht anpassen. Wenn man nur SMS als zweiten Faktor hinterlegt hat, könnten wir darauf hinweisen, dass sie auch GitHub Mobile, eine TOTP-App oder Sicherheitsschlüssel nutzen können. Möglicherweise steigen wir irgendwann auf einen direkteren Weg um, aber vorerst ist uns wichtig, dass Nutzer den sichersten zweiten Faktor hinterlegen, den sie jetzt gerade zur Verfügung haben.
c’t: Warum entscheiden die Nutzer sich nicht freiwillig für Zwei-Faktor-Authentifizierung?
Hanley: Das hat zwei Gründe. Wenn du Entwickler bist, dann trägst du nicht unbedingt die Konsequenzen für einen Sicherheitsvorfall. Das heißt nicht, dass ich dir schlechte Absichten unterstelle, ganz im Gegenteil. Aber wenn dein Account übernommen wurde, kann Schadcode schnell in ein Paket fließen, das von hunderten oder tausenden Leuten genutzt wird, weil es Teil einer Software-Lieferkette ist. Wenn ein Account nur mit einem Passwort gesichert ist, kann das erhebliche Auswirkungen haben. Außerdem glaube ich, dass viele Integrationen von Zwei-Faktor-Authentifizierung nicht gut umgesetzt sind.
c’t: In Bezug auf Nutzerfreundlichkeit?
Hanley: Ja, viele Sicherheitsexperten sind gut darin, Lösungen zu entwickeln, von denen wir glauben, dass sie das Beste für Nutzer sind, ohne mit ihnen zu sprechen. Aber das ist eine Falle. Vielleicht entwickelst du etwas, das sich auf eine Reihe von Annahmen stützt, aber gewöhnliche Nutzer oder Entwickler ohne Security-Hintergrund denken, 'Was soll das? So wie das funktioniert, ergibt das für mich keinen Sinn.'
c’t: Im Blogbeitrag, der die Umstellung ankündigt, steht, dass Nutzer, die 2FA nach der Frist nicht aktivieren, einige Features nicht mehr nutzen können, bis sie es tun. Welche sind das?
Hanley: Sie werden keinen Code mehr beisteuern können. Sie können sich aber weiterhin einloggen und die anderen Features von GitHub.com nutzen. Ich gehe davon aus, dass im Lauf des Jahres, je mehr Kohorten wir zu 2FA verpflichten, immer mehr Organisationen und Open-Source-Projekte auf GitHub, 2FA zur Bedingung machen, um Mitglied zu sein. Ich denke, das wird ein weiterer Anreiz, diese Anforderung zu erfüllen.
c’t: Die Vorteile von 2FA mögen für Organisationen auf der Hand liegen, aber viele Nutzer bleiben skeptisch. Als heise online über die 2FA-Pflicht bei GitHub berichtet hat, kommentierte ein Leser: "Was, wenn mein Haus abbrennt und meine Sicherheitsschlüssel, Smartphone und Backup-Keys futsch sind? Bin ich dann für immer aus meinem GitHub-Account ausgesperrt?" Was würden Sie antworten?
Hanley: Entwickler tragen die Verantwortung, sich um einen Backup-Plan zu kümmern. Der kann so aussehen, dass sie ihre Backup-Keys ausdrucken und an einem sicheren Ort aufbewahren, oder mehrere Sicherheitsschlüssel mit dem Account verknüpfen. Ich habe GitHub Mobile auf meinem Smartphone und mehrere FIDO2-Sicherheitsschlüssel verknüpft, die nicht alle bei mir im Haus sind, um sicherzustellen, dass ich den Zugriff auf Systeme und Infrastruktur nicht verliere. Wir raten allen Nutzern, so ähnlich zu verfahren.
Außerdem prüfen wir regelmäßig, ob Nutzer noch Zugriff auf ihre zweiten Faktoren haben, und investieren in unseren Support, damit wir helfen können, wieder Zugriff auf den Account zu verschaffen. Das gut zu machen ist aber eine der größten Herausforderungen. Durch den Recovery-Prozess Sicherheitslücken zu erzeugen, die Entwickler und ihre Konten gefährden, ist das Letzte, was wir wollen.
c’t: 2FA erhöht die Sicherheit, aber es gibt auch Schwachstellen, beispielsweise sogenannte MFA-Fatigue: Angenommen, ein Angreifer kennt Usernamen und Passwort eines Entwicklers und flutet jetzt das Smartphone des Opfers mit Autorisierungsanfragen, bis es akzeptiert. Wie kann dem begegnet werden?
Hanley: Die Autorisierung über GitHub-Mobile geht über eine simple Bestätigung hinaus. Man muss zusätzlich die angezeigten Ziffern mit den Ziffern im Webinterface abgleichen. Das ist nicht perfekt, weil sich ein Angreifer beispielsweise als IT-Support ausgeben könnte, um die Ziffern zu erfragen, aber das ist deutlich schwieriger als andere Prompt-Spamming-Attacken bei Push-basierten Verfahren, die diesen Mechanismus nicht enthalten.
(Bild: GitHub)
c’t: Was ist mit Reverse-Proxys, die sich als Seiten wie Google oder GitHub ausgeben, um dadurch TOTP-Tokens abzufangen oder Session-Cookies zu stehlen? Wir haben einige solcher Projekte auf GitHub gefunden.
Hanley: Die meisten dieser ausgefeilten Phishing-Angriffe setzen ein gewisses Maß an Täuschung oder Social Engineering voraus. Als Angreifer musst du dem Opfer eine URL vorsetzen, die wie GitHub.com aussieht. Oder du musst eine privilegierte Position im Netzwerk innehaben, um Opfern die Seite vorzusetzen. Einige Authentifizierungsmethoden sind anfällig für diese Angriffe. Der beste Schutz besteht darin, FIDO2-Sicherheitsschlüssel für WebAuthn als zweiten Faktor zu nutzen, weil sie resistent gegen Phishing sind.
Am 16. Mai dreht sich beim Online-Thementag der heise devSec alles um Zwei-Faktor-Authentifizierung. Das Programm bietet unter anderem Vorträge zur Zukunft von 2FA und MFA, zum Einsatz von WebAuthn und der Integration von TOTP sowie zu den Risiken bei der Implementierung von 2FA.
Bis zum 24. April sind Tickets für den von heise Developer, heise Security, iX und dpunkt.verlag ausgerichteten Thementag zum vergünstigten Frühbucherpreis erhältlich.
c’t: Sichere Authentifizierung ist ein wichtiger Schritt, um Software-Lieferketten abzusichern. Was kommt danach?
Hanley: Ich gehe davon aus, dass es noch mehr zu tun gibt, wenn wir die Umstellung auf 2FA-Pflicht am Ende des Jahres abschließen. Wir könnten zu dem Schluss kommen, dass bestimmte Gruppen von Entwicklern ein besonders attraktives Ziel sind, und ihnen zusätzliche Maßnahmen anbieten, um ihre Konten zu schützen. Möglicherweise bieten wir Gruppenrichtlinien für Entwickler und Organisationen an, die beispielsweise nur innerhalb von GitHub Codespaces entwickeln wollen, also in einer sicheren VM in der Cloud.
So arbeiten wir auch bei GitHub selbst. Alles entsteht in einer sicheren, gehosteten Entwicklungsumgebung namens Codespace, die wir auch unseren Kunden anbieten. Anstatt den Code, die lokalen Build-Umgebungen und die lokalen Entwicklungsumgebungen von tausenden Mitarbeitern zu schützen, können wir uns darauf konzentrieren, diesen Punkt zu schützen und müssen nur sicherstellen, dass all ihre Browser und Endgeräte aktuell sind und unseren Sicherheitsstandards genügen.
(ndi)