Base64 erklärt: Was es ist, warum es existiert und wann nicht

Sie sehen eine lange Kette aus Buchstaben und Ziffern, die auf == endet, und die Frage ist, ob das sensibel, verschlüsselt oder einfach kodiert ist. Es ist einfach kodiert. Das ist fast immer die Antwort, und zu verstehen warum dauert etwa eine Minute.

Die ganze Idee

Base64 stellt beliebige Bytes mit 64 druckbaren ASCII-Zeichen dar: A-Z, a-z, 0-9 und zwei weitere, dazu = als Padding. Kein Schlüssel, keine Kompression, keine Raffinesse. Es ist eine Nachschlagetabelle, und wer die Form erkennt, dreht sie um.

Der Name ist die Mechanik. Vierundsechzig Symbole sind sechs Bit pro Zeichen, und die Eingabe hat acht Bit pro Byte. Sechs und acht in Einklang zu bringen ist der ganze Algorithmus.

Nehmen Sie drei Bytes, also 24 Bit. Schneiden Sie sie in vier Gruppen zu sechs statt in drei Gruppen zu acht. Schlagen Sie jede Gruppe im Alphabet nach. Drei Bytes hinein, vier Zeichen heraus, daher die 33 Prozent Zuwachs.

Zeichen für Zeichen zusehen können Sie im Base64-Encoder/Decoder .

Padding, und wofür es da ist

Die Eingabe ist nicht immer ein Vielfaches von drei, das Ende wird also mit Nullbits aufgefüllt, und die Ausgabe bekommt =-Zeichen, die festhalten, wie viele echte Bytes es waren:

"Man"  ->  TWFu     drei Bytes, kein Padding
"Ma"   ->  TWE=     zwei Bytes, ein Gleichheitszeichen
"M"    ->  TQ==     ein Byte,   zwei Gleichheitszeichen

Deshalb ist der Zuwachs bei kurzer Eingabe schlimmer als 33 Prozent. Aus einem einzelnen Byte werden vier Zeichen. Das Verhältnis beruhigt sich erst bei langer Eingabe.

Warum es überhaupt existiert

SMTP, frühe HTTP-Header, URLs: Sie wurden gebaut, um Text zu transportieren. Geben Sie ihnen rohe Binärdaten, und Steuerzeichen werden interpretiert, hohe Bytes verstümmelt, Zeilenenden von irgendeiner hilfreichen Zwischenstation umgeschrieben. Base64 garantiert, dass jedes Ausgabezeichen druckbar und langweilig ist, damit es die Reise übersteht.

Bei Base64 geht es nicht um Geheimhaltung. Es geht darum, eine reine Textleitung zu überleben.

Drei Varianten und die Fehler, die sie verursachen

Standard-Base64 nutzt + und / für die Werte 62 und 63. Beide sind in einer URL unpraktisch, also definiert RFC 4648 ein zweites Alphabet mit - und _ an ihrer Stelle, und diese beiden Zeichen sind der einzige Unterschied¹.

JWT geht dann noch einen Schritt weiter. RFC 7515 definiert seine Kodierung als base64url "with all trailing '=' characters omitted"², was zulässig ist, weil RFC 4648 Padding nur verlangt, solange die nutzende Spezifikation nichts anderes sagt¹.

Und MIME legt das Ganze um und verlangt Zeilen von höchstens 76 Zeichen³, weshalb in einer aus einer E-Mail kopierten Zeichenkette plötzlich Zeilenumbrüche stecken.

Ein Fehler "ungültiges Base64" ist meist eines von drei Dingen:

1. Eine URL-sichere Zeichenkette an einen Standard-Decoder, oder umgekehrt.
2. Padding, das unterwegs entfernt oder ergänzt wurde.
3. Zeilenumbrüche, die aus MIME mitgekommen sind.

Und das ist keine Cognito- oder Auth0-Eigenart, wie es oft beschrieben wird. Jedes JWT von jedem Aussteller ist base64url ohne Padding, weil die Signatur-Spezifikation es so vorschreibt. Ein selbstgebauter Prüfer mit Standard-Decoder lehnt sie alle gleichermassen ab.

Wo es sich lohnt

Data-URLs. Ein kleines Bild, eine Schrift oder ein SVG direkt in CSS oder HTML einbetten, mit data:image/png;base64,.... Das spart eine Anfrage, kostet ein Drittel mehr Bytes und verhindert getrenntes Caching. Für ein Icon lohnt es sich, oberhalb weniger Kilobyte selten. Unsere Tools Bild zu Base64 und Base64 zu Bild decken beide Richtungen ab.

JWT-Segmente. Alle drei Teile eines Tokens sind base64url ohne Padding, und der mittlere enthält die Claims. Kodiert, nicht verschlüsselt: Wer den Token hat, kann ihn lesen.

Binärdaten in JSON oder YAML. Ein PEM-Schlüssel in einem Konfigurationsfeld, wo die Alternative ein Escaping-Problem ohne Ende ist.

E-Mail-Anhänge. Weiterhin die Standardkodierung in MIME-Multipart-Bodies, also genau die Aufgabe, für die Base64 erfunden wurde.

Eine Stelle verlangt Vorsicht, obwohl sie in jedem "Logo einbetten"-Tutorial auftaucht: E-Mail-Signaturen. Die übliche Warnung lautet, Gmail stelle Data-URIs nicht dar, und das stimmt seit Anfang 2020 nicht mehr - Gmail unterstützt sie im Web, unter iOS und unter Android. Das Problem ist der lange Schwanz dahinter. Outlook unter Windows stellt base64-GIFs nicht dar, mehrere Webmail-Clients akzeptieren nur PNG, und einige schreiben das src-Attribut so um, dass gar nichts lädt. Damit liegt die Unterstützung bei rund 81 Prozent der getesteten Clients.⁴

Für etwas, das sich nach dem Senden nicht mehr prüfen lässt, ist das eine schlechte Zahl. Jede fünfte Empfängerin sieht eine kaputte Signatur, ohne dass Sie je eine Fehlermeldung bekommen - schlechter als das Hosting, das Sie sich sparen wollten. Hosten Sie das Bild und verlinken Sie es.

Wo es nicht hingehört

Geheimhaltung. Ein Einzeiler macht es rückgängig. "Das Passwort ist Base64-kodiert" beschreibt ein Klartext-Passwort mit Zusatzschritt.

Kompression. Es bläht Daten um ein Drittel auf. Ist die Nutzlast zu gross, greifen Sie zu gzip oder brotli, und beachten Sie, dass Base64 auf komprimierten Daten einen Teil der eben bezahlten Kompression wieder auffrisst.

Grosse Binärdaten in einer Datenbank. Eine BLOB-Spalte liest schneller, schreibt schneller und ist ein Drittel kleiner. Base64 in einer TEXT-Spalte ist meist etwas, das passiert ist, nicht etwas, das entschieden wurde.

Undurchsichtige IDs in URLs. Hex oder eine dafür gebaute URL-sichere ID umgeht die Padding- und Alphabetfragen vollständig.

Erkennen, und die Falle beim Erkennen

Die Formprüfung ist einfach:

^[A-Za-z0-9+/]*={0,2}$     Standard
^[A-Za-z0-9_-]*={0,2}$     URL-sicher

Und sie beweist fast nichts. password sind acht Zeichen aus dem Alphabet mit einer durch vier teilbaren Länge, also gültiges Base64. Es dekodiert zu sechs Bytes, die nichts bedeuten. Jede Zeichenkette der passenden Form und Länge besteht diesen Test.

Der einzige echte Test ist, zu dekodieren und anzusehen, was herauskommt.

Womit wir beim zeitraubendsten Fehler wären: doppelte Kodierung. Ein System speichert etwas bereits Kodiertes, kodiert es beim Senden erneut, und die Empfängerseite dekodiert einmal, bekommt wieder etwas Base64-Ähnliches und beginnt, ihren Parser zu debuggen. Sieht die dekodierte Ausgabe noch kodiert aus, ist sie es vermutlich. Dekodieren Sie noch einmal.

Base64 lässt Binärdaten Text überleben. Es macht sie nicht kleiner und nicht geheim. Fast jeder Fehler damit ist eine falsche Variante, ein falsches Padding oder eine Runde zu viel.