Base64 kodieren

Base64 ist eine Art, Bytes aufzuschreiben, keine Art, sie zu verbergen. Es gibt keinen Schlüssel, nichts ist geheim, und wer das Ergebnis hat, liest es in einer Sekunde zurück — was auch der Sinn der Sache ist, denn die Gegenstelle muss das ja können. „Kodiert“ statt „verschlüsselt“ zu sagen ist keine Erbsenzählerei, sondern der Unterschied zwischen einem Transportformat und einer Schutzmaßnahme.

Das wird an einer Stelle konkret: beim Header `Authorization: Basic`, der aus Benutzername und Passwort besteht, verbunden durch einen Doppelpunkt und Base64-kodiert. Das ist kein Schutz irgendeiner Art, und es ist der Grund, warum Basic Auth über unverschlüsseltes HTTP dem Versand des Passworts im Klartext gleichkommt. Über HTTPS ist es in Ordnung, weil dort TLS die eigentliche Arbeit macht.

Der Algorithmus nimmt die Eingabe in Dreierschritten — vierundzwanzig Bit — und schneidet sie neu in vier Gruppen zu sechs Bit, von denen jede einen Platz in einem 64 Zeichen langen Alphabet bezeichnet. Sechs Bit adressieren genau vierundsechzig Werte; daher der Name und daher die krumme Größe des Alphabets.

Daraus folgt ein fester Preis: Das Ergebnis ist immer etwa ein Drittel größer als die Eingabe, plus Padding. Ein 3-MB-Bild, das als Data-URI eingebettet wird, ergibt 4 MB Markup. Das ist der Preis für die Garantie, und deshalb gehört Base64 in Header, kleine Payloads und überall dorthin, wo Text vorgeschrieben ist — und nicht vor eine Datei, die man ebenso gut als Bytes hätte hochladen können.

Das Standardalphabet endet auf `+` und `/`. Beide bedeuten in einer URL etwas anderes — `+` ist im Query-String ein Leerzeichen, `/` trennt Pfadteile —, also geht ein Base64-Wert in einer URL entweder kaputt oder wird still von dem verändert, was ihn als Nächstes anfasst. RFC 4648 §5 definiert die Lösung: stattdessen `-` und `_`, und das abschließende `=` fällt weg, weil es ebenfalls reserviert ist.

Genau das benutzen JWTs. Jedes Segment eines Tokens ist URL-sicheres Base64 ohne Padding — und das ist zugleich der Grund, warum so viele Decoder sie ablehnen: Ein Decoder, der auf Padding besteht, weist jedes echte Token zurück, das ihm untergekommen ist. Der auf dieser Website stellt das Padding vor dem Dekodieren wieder her und kümmert sich deshalb nicht darum.

Base64 kodiert Bytes, und ein String ist erst dann Bytes, wenn man sich für eine Kodierung entschieden hat. Wird dieser Schritt falsch gemacht, sieht trotzdem alles gut aus, weil sich alle Implementierungen bei ASCII einig sind — der Fehler bleibt unsichtbar, bis jemand einen Namen mit Umlaut eingibt.

Der Klassiker ist JavaScripts eigenes `btoa`, das bei allem oberhalb von U+00FF schlicht eine Exception wirft, und der klassische Behelf ist schlimmer: Wandelt man mit `charCodeAt` um, bekommt man ein Byte pro Codeeinheit, also wird aus `ü` ein `FC`, wo in der Datei `C3 BC` steht. Diese Seite kodiert durchgehend UTF-8, weshalb „Grüße“ heil zurückkommt — und weshalb genau dieser String und nicht „hello“ in den Tests steht.

Data-URIs, damit ein kleines Symbol im Stylesheet leben kann statt einen Request zu kosten. MIME, damit ein Anhang einen Mailserver übersteht, der älter ist als der 8-Bit-Transport. Basic-Auth-Header. JWT-Segmente. PEM-Dateien, die nichts anderes sind als DER-Bytes in Base64 zwischen zwei Strichzeilen.

Kubernetes-Secrets sind der Fall, wegen dem die meisten das hier zum ersten Mal nachschlagen: Sie sind Base64 in YAML, was regelmäßig für Verschlüsselung gehalten wird und keine ist. Gemeinsam ist all diesen Fällen ein Kanal, der für Text spezifiziert wurde und nun etwas anderes tragen soll. Base64 ist der Adapter. Wo der Kanal mit Bytes zufrieden ist — ein Datei-Upload, ein Request-Body —, kostet es ein Drittel und bringt nichts.

Die ein oder zwei Gleichheitszeichen am Ende sind Auffüllung. Weil der Algorithmus in Dreierschritten arbeitet, bleibt bei einer Eingabelänge, die kein Vielfaches von drei ist, am Schluss eine kurze Gruppe übrig, die auf vier Zeichen aufgefüllt wird. Ein Gleichheitszeichen heißt: zwei Bytes waren übrig; zwei heißen: eines.

Weglassen darf man es dort, wo die Länge ohnehin bekannt ist oder wo `=` stört — in URLs also, und damit in JWTs. Beim Dekodieren ist das folgenlos, solange der Decoder es wiederherstellt. Beim Vergleichen zweier Base64-Werte als Strings ist es nicht folgenlos: Derselbe Inhalt einmal mit und einmal ohne Padding ist zeichenweise ungleich, und das ist ein Fehler, der eine Code-Review überlebt, weil beide Werte auf dem Bildschirm gleich aussehen.

Manche Base64-Ausgaben sind nach 64 oder 76 Zeichen umbrochen. Das ist kein Zufall und kein Schönheitsdienst, sondern MIME: Mailsysteme hatten Zeilenlängenbegrenzungen, und PEM-Dateien halten die Konvention bis heute ein, weshalb jedes Zertifikat, das du je in einem Editor geöffnet hast, so aussieht.

Für einen Decoder sind diese Umbrüche Rauschen und werden verworfen — auch von dem hier. Für einen String-Vergleich sind sie es nicht: Dieselben Daten einmal umbrochen und einmal nicht sind zwei verschiedene Zeichenketten. Wer Base64 in eine Konfigurationsdatei oder eine Umgebungsvariable schreibt, will die einzeilige Form.

Kodieren wirkt harmloser als Dekodieren — man erzeugt ja etwas, statt etwas offenzulegen. Nur ist das, was hier hineingeht, oft genau dasselbe Material: ein Passwort für einen Basic-Auth-Header, ein Zugangstoken, das in eine Konfigurationsdatei soll, ein Client-Secret für eine Testanfrage.

Diese Werte durch einen fremden Server zu schicken, damit er ein Drittel mehr Zeichen daraus macht, ist die schlechteste denkbare Gegenleistung. Die Rechnung sind ein paar Zeilen, die dein Browser in Mikrosekunden erledigt, und das Netzwerk-Panel zeigt währenddessen nichts.

Ein häufiger und selten erklärter Fall: Ein Zertifikat, ein Schlüssel oder eine Dienstkonto-Datei soll in eine Umgebungsvariable, und Umgebungsvariablen vertragen keine Zeilenumbrüche. Base64 macht daraus eine einzige Zeile, die jede CI-Oberfläche, jedes Secret-Feld und jede Deployment-Konfiguration annimmt.

Wichtig ist dabei die einzeilige Form ohne Umbrüche — die umbrochene Variante aus der MIME-Welt bringt genau das Problem zurück, das gelöst werden sollte. Und es bleibt eine Verpackung: Der Wert in der Variable ist nach wie vor im Klartext lesbar für jeden, der die Variable lesen darf. Base64 ändert daran nichts, es macht die Datei nur transportfähig.