Base64 kodieren und dekodieren

Wozu es da ist

Base64 löst ein Problem: Sie haben beliebige Bytes und einen Kanal, der nur druckbaren Text transportiert. E-Mail-Header, JSON-Zeichenkettenfelder, URLs, HTML-Attribute und ein gut Teil älterer Infrastruktur kommen mit rohen Binärdaten nicht zurecht. Base64 bildet je drei Bytes auf vier Zeichen aus einem 64-Symbol-Alphabet ab, das all das übersteht.

Das ist der ganze Zweck. Es ist keine Kompression — die Ausgabe ist ein Drittel größer. Es ist keine Verschlüsselung — es gibt keinen Schlüssel. Es ist eine Transportkodierung, und jede Eigenschaft, die man ihr fälschlich zuschreibt, entspringt der Verwechslung von „ich kann das nicht lesen“ mit „das ist geschützt“.

Wo Sie ihm begegnen

• JWTs. Alle drei Segmente, im URL-sicheren Alphabet und ohne Auffüllung.
• HTTP-Basic-Auth. Authorization: Basic ist einfach user:password in Base64 — genau deshalb ist Basic-Auth über einfaches HTTP gleichbedeutend damit, das Passwort im Klartext zu senden.
• Data-URIs. data:image/png;base64,... bettet eine Datei direkt in HTML oder CSS ein.
• PEM-Zertifikate und -Schlüssel. Die Zeilen zwischen -----BEGIN----- und -----END----- sind Base64-kodiertes DER.
• E-Mail-Anhänge. SMTP ist ein Textprotokoll; MIME nutzt Base64, um alles zu transportieren, was keiner ist.

Die Unicode-Falle

Der Browser gibt Ihnen btoa und atob, und sie sind eine Falle. Beide arbeiten auf Bytes, dargestellt als Zeichenkette, weshalb btoa bei jedem Zeichen oberhalb von U+00FF eine Ausnahme wirft. Probieren Sie es mit einem Emoji und Sie erhalten InvalidCharacterError.

Die Lösung ist, zuerst in UTF-8-Bytes umzuwandeln, und genau das tut diese Seite:

// Encode any string safely
const bytes = new TextEncoder().encode(text);
const b64 = btoa(String.fromCharCode(...bytes));

// Decode back
const binary = atob(b64);
const out = new TextDecoder().decode(
  Uint8Array.from(binary, c => c.charCodeAt(0))
);

Eine Einschränkung zur Kodierzeile: Ein großes Array in String.fromCharCode zu spreizen, überläuft irgendwo bei hunderttausend Elementen den Aufrufstapel. Für Größeres schleifen Sie in Blöcken — diese Seite tut das, weshalb sie ein mehrere Megabyte großes Einfügen verkraftet, ohne umzufallen.

Die zwei Alphabete

Die Auffüllung macht den Ärger. Ihre einzige Aufgabe ist, die Länge auf ein Vielfaches von vier zu bringen, und ein Decoder kann stets ausrechnen, wie viel fehlt — deshalb lässt die URL-sichere Variante sie weg. Strenge Decoder weisen das Ergebnis dann zurück, weshalb ein in ein anderes Werkzeug eingefügtes JWT-Segment so oft scheitert. Der Decoder hier stellt die Auffüllung selbst wieder her.

Wo er missbraucht wird

Weil Base64 auf den ersten Blick unlesbar ist, wird es benutzt, als wäre es ein Geheimnis. Die konkreten Muster gehören benannt:

• Base64 als Passwortspeicher. Das ist Klartext im Kostüm. Passwörter brauchen einen langsamen Einweg-Hash — bcrypt, scrypt, Argon2.
• Base64 in einem JWT-Payload, als wäre er privat. Der Payload ist für jeden lesbar, der das Token hat, auch für den Nutzer selbst. Legen Sie dort nie etwas hinein, das Sie ihm nicht zeigen würden.
• Base64, um Daten an einem Filter vorbeizuschmuggeln. Es funktioniert, kurz, und jeder brauchbare Scanner dekodiert es ohnehin.

Die Regel, die alle drei abdeckt: Wenn die Sicherheit einer Sache davon abhängt, dass der Leser sie nicht dekodiert, hat sie keine Sicherheit.

Verwandt

Der JWT-Decoder zerlegt ein Token und parst beide Segmente in einem Schritt. Wenn es ums Maskieren von Text geht, der in eine URL soll, statt ums Kodieren von Bytes, ist Prozentkodierung die andere Sache, die Sie vermutlich meinen. Und wenn das Dekodierte sich als JSON entpuppt, bringt der Formatter es in Form.