GitHub will nun "Tokens" für den Zugriff

Sonstiges Software
1

Wenn ich an der Kommandozeile etwas committe und auf GitHub pushe, bekomme ich seit kurzem eine Mail, die sagt

Basic authentication using a password to Git is deprecated and will soon no longer work.

Ein Link führt nach https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ , wo beschrieben steht, was man tun soll.

Die Frage, die sich mir aufdrängt, und die so infantil wirkt, dass ich zögere, sie zu stellen:

Warum?

Wenn ich das richtig verstanden habe, ist der vorgesehene Prozess nun so, dass man auf GitHub ein Token generiert, und das statt des Passworts verwendet. Und natürlich wird irgendwo irgendwelcher shyce dabei nicht funktionieren, weil … irgendwas mit SSH (und ich weiß nicht mal, was das ist), oder weil irgendwo ein Tool nicht mitspielt, das man verwendet und das gut seinen Zweck erfüllt, und wo die neue Version nicht richtig funktioniert und und und und… (ich hasse das…).

Kann jemand einem kompletten Netzwerk/Sicherheitsnoob kurz erklären, warum es so ungeheuer viel sicherer ist, wenn man den String "dasIstNichtWirklichMeinPasswort" duch den String "AE2VjZHNhLXNoYTItbmlzdHAyNTYAAAA..." ersetzt, den man dann zwangsläufig in einer MeinSuperGeheimesToken.txt auf dem Desktop rumfliegen haben muss?

2

Nun, das sollte auf der Hand liegen. Wenn jemand Dein Passwort herausfindet, kann er viel Unheil damit anrichten, und ggf. verwendest Du das gleiche Passwort sogar bei mehreren Diensten. Wenn aber jemand das Token herausfindet, kann er nicht so viel „accountbezogenes“ Unheil anrichten. Außerdem müssen wir davon ausgehen, dass kein System sicher wäre usw. usf. :no_mouth:

Angriffsvektoren gibt es viele, auch https soll ja schon Schwächen gehabt haben (es sei mal der Begriff „Man-in-the-Middle-Angriff“ in den Raum geworfen). SSH ist btw. ein kryptographisches Netzwerkprotokoll, vielleicht vergleichbar mit FTP, das meistens sicher ist.

3

Verschiedene Tokens für verschiedene Zwecke / Dienste…
z.B. Tokens für Github Actions (verschiedene Zugriffe) etc. weil es in der Zwischenzeit eine ganze Menge Dienste auf GitHub gibt… auch Zugriffe von anderen Systemen wie z.B. circleci, azure, drone, sonarquebe etc.
Alle diese Tools/Dienste benötigen Zugriffe auf meine Repositories oder ich auf andere Repositories und auch da ich ich in anderen Orgas zugehöre aber meinen eigentlichen Zugang will ich nirgendwo angeben (weil ja 2FA; Sonst hebelt man das ja wieder aus) aus diesem Grund Tokens… Ich benutze Tokens schon eine lange Zeit…

Gruß
Karl Heinz

4

Dass es Szenarien gibt, wo man solche Tokens gebrauchen kann, ist klar. Und dass man überall unterschiedliche Tokens/Passwörter hat, auch. Aber für die normale, „händische“ Benutzung erschließt es sich mir nicht. Bisher habe ich mein Passwort eingetippt. Jetzt werde ich ein Token copy+pasten (falls das alles denn so funktioniert, wie es sollte… vermutlich nicht… Computer funktionieren halt nie so, wie sie sollten). Jeder, der das Token hat, kann in meinem Repo irgendwelchen Mist machen - d.h. genau den gleichen Mist, für den ich sonst das Passwort verwende: Code committen.

Eine Argumentation/Formulierung, die einleuchtend klingen könnte, wäre sowas wie: „Das Passwort ist das Master-Passwort, und die Tokens sind kleine Unter-Passwörter für einzelne Aufgaben“. Aber wenn es außer „code committen“ nichts gibt, erscheint das ziemlich überflüssig.

(Und… vermutich wird es nicht richtig funktionieren. Mich nervt schon der „Credential Manager“, der sich manchmal woher auch immer (!?) beim Eintippen des Passworts einklinkt… nein, ich will es nicht speichern, ich tippe es ein… )

5

In dem Fall, dass jemand an den Token kommt, kannst du aber einfach den Token löschen lassen und alles andere bleibt „sicher“ bzw. unangetastet.
Wenn jemand ein Passwort bekommt, kann er alles löschen, wenn er den Token bekommt, nunja, das was für den Token alles erlaubt wurde

6

Ich kann ja kurz erklären, wie es bei meiner Uni funktioniert… Das Git ist nur über das VPN der Uni erreichbar, zusätzlich braucht man ein Token und Ssh… (Paranoia 1.0)

Wenn man so will, so braucht man also zwei Passwörter, zwei Verschlüsselungswege und ein „Token“/Fingerprint.

7

Die Frage, die sich mir aufdrängt, und die so infantil wirkt, dass ich zögere, sie zu stellen:

Nicht zögern. Sonder es ist sehr gut, dass Du fragst…

Wenn ich an der Kommandozeile etwas committe und auf GitHub pushe, bekomme ich seit kurzem eine Mail, die sagt

Was mir dabei noch einfällt… nicht falsch verstehen aber echt jetzt noch mit Username/Passwort Authentifizierung für Pushes? Das bedeutet auch, dass Du keinen 2FA für Deinen GitHub Account hast… Hm…

Warum kein SSH Key? Hatte ich eben noch überlesen… Dann noch die Frage: Signierst Du Deine commits per GPG Key ?

Ich würde Dir dringen Raten Dich mit ssh & co. zu beschäftigen und es zu nutzen…

Aber für die normale, „händische“ Benutzung erschließt es sich mir nicht. Bisher habe ich mein Passwort eingetippt.

Hm… also bei jedem Push…

Jetzt werde ich ein Token copy+pasten (falls das alles denn so funktioniert, wie es sollte… vermutlich nicht… Computer funktionieren halt nie so, wie sie sollten).

Ist das jetzt Erfahrung… ? Ich nutze Tokens seit ca. 4 Jahren (ssh-key verwende ich schon seit ich auf GitHub bin ca. 2008 )… ich habe selten das Problem gehabt, dass was nicht funktioniert hat… und das Problem saß bzw. sitzt dann meistens vor der Tastatur…

Jeder, der das Token hat, kann in meinem Repo irgendwelchen Mist machen - d.h. genau den gleichen Mist, für den ich sonst das Passwort verwende: Code committen.

Ja korrekt aber eben dann nur in dem einen Repo… und nicht mit allen Zugängen und Repos …abgesehen davon hast Du ja Dein Repo noch auf deinem Rechner (und so hoffe ich noch ein Backup davon)… somit kannst Du es sehr einfach wieder den richtigen Zustand zurück versetzten… 100% Sicherheit gibt es nicht das ist klar…
Weiterhin wenn jemand per Token auf ein Repo Zugreift oder auch den Login hinbekommt, dann bekommst Du von GitHub eine EMail, dass da was über eine andere Lokation passiert (seit ca. 2 Jahren)…

Eine Argumentation/Formulierung, die einleuchtend klingen könnte, wäre sowas wie: „Das Passwort ist das Master-Passwort, und die Tokens sind kleine Unter-Passwörter für einzelne Aufgaben“. Aber wenn es außer „code committen“ nichts gibt, erscheint das ziemlich überflüssig.

Einem Token kann man sehr genau die Berechtigung definieren. Ja leider nur in globaler Form (im praktischen aber kein Problem) (GitHub). Es gibt eine weitere Möglichkeit, dass man einen sog deploy-key der dann Repository bezogen ist vergibt…

Also mit einem Token kann man eine Ganze menge machen außer committen…(z.B. Release Notes erstellen https://github.com/khmarbaise/smpp/releases)…

Und… vermutich wird es nicht richtig funktionieren. Mich nervt schon der „Credential Manager“, der sich manchmal woher auch immer (!?) beim Eintippen des Passworts einklinkt… nein, ich will es nicht speichern, ich tippe es ein… )

Ich speichere meine Passwörter und Zugänge in einem Passwort Container… da ich über 150 verschiedene Zugänge habe… das kriegt mein Hirn einfach nicht mehr hin… Eintippen … nein geht nicht mehr (dauert schlicht zu lange) … bei Passwörtern, die 30+ Zeichen haben wird das langsam schwierig da ist dann Copy&Paste vom Container angesagt (leider gibt es immer noch Systeme, die die Passwortlänge auf max. 8/12 Zeichen begrenzen… ).

BTW: Ein Wichtiger Unterschied zwischen einem Token und einem Passwort ist, dass manuell Passwörter oft mit Hilfe einer Dictonary Attacken zu ermitteln sind, während das bei Token und generierten Passwörtern deutlich unwahrscheinlicher ist…

Ergänzung: Für Tokens auf GitHub die im Rahmen von GitHub Actions verwendet werden erzeugt GitHub entsprechende Tokens, die nur innerhalb des Repositories Gültigkeit haben… (https://docs.github.com/en/free-pro-team@latest/actions/reference/authentication-in-a-workflow)

8

Sicher. (Pun intended). Ich habe zwar inzwischen auch ein Smartphone, aber eines von dem, was da an Infrastruktur und Workflows aufgebaut wird, erschließt sich mir einfach nicht. Spätestens, wenn ich das Ding mit meinem „echten“ E-Mail-account verknüpfen würde, wäre 2FA genauso sicher wie 1FA oder 99FA: Wer das Ding in der Hand hat, hätte dann volle Kontrolle über alles. Das Smartphone wäre damit der „weakest Link“, der wackeligste Baustein in einer höchst kritischen Infrastruktur. Jedenfalls würde ich es dann nicht mehr in der Hosentasche mit mir rumtragen, sondern zuhause lagern - vielleicht in einem Safe…

Ich habe hier irgendwo SSH keys. (Ich glaube, ohne die kann man gar nichts auf GitHub bringen, oder?). GPG spielt auch irgendwo mit rein, aber damals hat bei mir das Maven Release Plugin da in einer Weise quergeschossen, dass das… sagen wir mal… nicht mehr den eigentlichen Zweck erfüllt (Details lasse ich hier mal weg). Ich hatte mich, als GitHub „in“ wurde, damit gerade so weit beschäftigt, dass ich meinen (belanglosen, Open-Soruce-MIT-Lizenz) Kram halt irgendwie öffentlich machen kann.

Vorher waren es halt ZIP-Dateien, die ich per FTP auf eine Webseite gepackt habe. Vielleicht kehre ich wieder dahin zurück - ist vielleicht sinnvoller.

(BTW: Hier lokal habe ich für bestimmte Sachen BAT-Dateien, in denen git push https://username:password@github.com/... drinsteht - das sollte nicht so sein, das weiß ich, und ich mag das nicht, aber wenn die Alternative darin besteht, erstmal ein „Aufbaustudium IT-Sicherheit“ zu durchlaufen, nur um Code auf eine Webseite zu bringen, der dort Open Source sein wird, dann wäge ich eben Aufwand und Nutzen ab…)

Dass damit vieles möglich ist, was („nur“) mit einem Passwort nicht möglich ist, weiß ich. Aber wenn es wirklich nur darum geht, belanglosen, offenen Code auf eine Webseite zu bringen, will ich nicht bei jedem push durch einen Haufen Reifen springen müssen (und mit einem Smartphone mit irgendeiner Authenticator-App hantieren).

(Und ja, als ich mal für was externes „LastPass“ verwenden sollte, hat das auf meinem (wie gesagt recht neuen) Smartphone schlicht nicht funktioniert - da ist ein Knopf, man tippt drauf, und es passiert einfach nichts. Ich meine, nicht dass da eine komplizierte Fehlermeldung gekommen wäre, oder ich irgendwas beim Aufsetzen der Infrastruktur falsch gemacht haben könnte. Man installiert es, tippt auf einen Knopf, und es passiert einfach nichts… alles Mist)

Edit: Ich kann mir zwar jetzt https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ durchlesen, und die verlinkten Seiten darin, und die verlinkten Seiten darin, und die verlinkten Seiten darin, while (!amSecurityExpert()) { ... }, aber vielleicht kann jemand kurz skizzieren, wie eine BAT mit git push https//username:password... durch das neue, sichere (?) System ersetzt werden könnte. Einfach password durch token ersetzen? Wohl eher nicht …

9

Spezifische Token sollen hiervor schuetzen:

Ich bin kein „Sicherheitsexperte“, persoenlich finde ich die Aenderung umstaendlich.
Ich finde es auch doof wenn es IMO „wirre“ Regeln gibt fuer Passwoerter (Gross- und Kleinbuchstaben, Zahlen, Sonderzeichen und drei tropfen Jungfernblut, alle 2 Wochen ein neues, etc. pp.).