Bitbucket App-Passwords

« | 30 Jan 2022 | »

Am 1. November wurde es angekündigt und am 1. März 2022 ist es so weit:

Bitbucket sperrt User Passwörter für den Zugang zu seinen GIT Repos.

Die Alternative sind SSH Schlüssel oder “App-Passwörter”.

---

Vorgeschichte

Früher funktionierte Authentifizierung immer nach dem User + Passwort Prinzip. Jedes Protokoll ( HTTP, FTP, SSH, SMTP, POP3, IMAP, …) implementierte sein eigenes Format, in welchem der Benutzer und sein Passwort übertragen werden konnte.
… und leider haben sie es alle absolut falsch gemacht.
Denn das Passwort wurde immer im Klartext übertragen, und obgleich später durch Protokollerweiterungen auch Hashes und andere Späße eingearbeitet wurden, so waren und sind Klartextpasswörter in den meisten Diensten möglich, außer wenn sie explizit abgeschaltet sind.

Es fehlte an einem Standard, wie Passwörter sicher übertragen werden konnten.

SSL und TSL sicherten dann zwar die Datenverbindung zwischen zwei Systemen, doch da im Hintergrund immer noch Klartextpasswörter eingesetzt wurden, ergaben sich immer noch andere Stellen, wo das Passwort abgefangen und gestohlen werden konnte.

Zertifikate wäre ja eine schöne Sache gewesen um dieses Problem zu lösen, doch wie trägt man ein solches immer mit sich herum?

API Token

Anstatt also immer Namen + Passwort zu nutzen, dachte man sich für diverse Automationsprozesse API-Token aus. Der immer noch per Name + Passwort authentifizierte Benutzer kann in einer gesicherten Umgebung zufällige Token generieren lassen, die als Ersatz für Name/Passwort gelten und da man diese Token auch nur mit Teilrechten ausstatten konnte, ergab sich somit eine neue Welt für Web-Anwendungen.

Viele Web-Zugriffe laufen heute über solche Token und nun stellt auch Bitbucket auf dieses Verfahren um.

In Zukunft muss ich also mein “App-Password” == App-API-Token parat haben, wenn ich Sourcecodes hoch- oder herunterladen möchte.
Sollte es mir verloren gehen, kann ich es sperren und ein neues anlegen.

Doch bei meinem ersten Login per TortoiseGIT lief es mir kalt über den Rücken…

Das Browser-Problem

Während früher User+Passwort fixe Felder in Protokollen waren, gehen heute mehr und mehr Dienste dazu über, die Dateneingabe über Webseiten laufen zu lassen, wo am Ende ein finaler Zugriffstoken auf die Daten nach der Anmeldung herausfällt.

Hierfür öffnen die Apps tatsächlich HTML Webformulare, um stets dem “neuesten” Sicherheitsstand (oder dem neuesten UI Logo) nachlaufen zu können.

Genau diese schleichende Browser-isierung von Netzdiensten empfinde ich persönlich als “Bedrohung des Endanwenders”, obwohl es eigentlich der Sicherheit dienen sollte.
Denn an der Stelle findet erneut ein Browser-Krieg statt, der mir das Arbeiten mit nicht-top-aktuellen Systemen übelst erschwert.

Das fängt leider damit an, dass immer mehr Javascript Code aktiv ausgeführt werden muss, damit ein Login auf einer solchen Webseiten überhaupt funktionieren kann.
Folglich kann ich auf einer nicht-grafischen Konsole keinen Login mehr durchführen, weil mir dort ein Browser fehlt, der die Loginmaske adäquat anzeigen könnte.

Bitbucket Web-Login nur beim ersten Mal

TortoiseGIT hat das Feature bereits integriert und so öffnet sich beim ersten Login eine Webseite, die das “App-Passwort” erkennt und die nötige Freigabebestimmung abfragt.

Zum Glück gilt das Passwort dann an der Stelle als “safe” und kann auch wieder regulär über native Protokolle benutzt werden.
Somit kann ich auch auf meinem Linux VMs und Raspberry-PIs weiter mit GIT über HTTPS und dem neuen “App-Passwort” arbeiten.

Das App-Passwort ist mit seinen 20 Zeichen kurz genug, um es als Text “mitführen” zu können, womit mir die Einrichtung von SSL-Zertifikaten auf allen Maschinen vorerst erspart bleibt.

Fazit

Ja, es war bisher immer “unsicher”, wenn ich bei jedem git pull mein Passwort habe übertragen lassen und die neuen App-Passwords machen diesen Teil um einiges sicherer.

Dennoch frage ich mich, wie der initiale Login per Webinterface in Zukunft aussehen wird, bzw. wie viele System damit ausgeschlossen werden.

Auf meinem Windows Phone von 2017/2018 laufen inzwischen viele Logins deshalb überhaupt nicht mehr, weil sich das Web zu sehr weiterentwickelt hat, während klassische Logins mit User + Passwort bei Mailaccounts dort auch weiter kein Problem sein werden.

Es bleibt daher nur zu hoffen, dass künftige Umstellungen von Loginprozeduren nicht so gestaltet sind, dass nur noch auf Android oder Apple Smartphones ausführbar sind.
Denn zu meinem großen Bedauern geht der Trend leider in diese Richtung.