Kurz gesagt
Base64 schreibt eine beliebige Folge von Bytes mit 64 unproblematischen Zeichen (A–Z, a–z, 0–9, +, /). Es dient dazu, Binärdaten wie ein Bild, ein PDF oder einen Schlüssel durch Systeme zu schleusen, die nur mit Text umgehen können: E-Mail-Texte, JSON-Strings, URLs, HTML-Attribute. Base64 ist eine Kodierung und keine Verschlüsselung. Es gibt keinen Schlüssel, und zum Dekodieren genügt ein einziger Funktionsaufruf, den jede Programmiersprache und die Entwicklerkonsole jedes Browsers bereitstellt. Ein Passwort, das „in Base64“ gespeichert ist, liegt im Klartext vor, nur mit einem Zwischenschritt.
Warum es Base64 gibt
E-Mail wurde in den 1970er-Jahren für 7-Bit-ASCII entworfen. Als Anhänge dazukamen (MIME, 1992), mussten die Bytes eines JPEG als harmloser Text getarnt werden. Ein JPEG nutzt alle 256 Werte, auch solche, die für einen Mailserver „Zeilenende“ oder „Nachrichtenende“ bedeuten. Die Lösung war Base64: drei Bytes (24 Bit) nehmen, in vier Gruppen zu 6 Bit aufteilen und jede Gruppe einem von 64 Zeichen zuordnen. Aus je 3 Bytes werden 4 Zeichen. Das ist der bekannte Mehraufwand von 33 %: Ein Anhang mit 3 MB ergibt eine E-Mail mit 4 MB, und deshalb passt in ein Mail-Limit von „25 MB“ eine Datei mit 18 MB.
Derselbe Trick taucht überall dort auf, wo Text der einzige Kanal ist: beim direkten Einbetten eines kleinen Bildes in eine Webseite (data:image/png;base64,…), bei einem binären Token im HTTP-Header (Authorization: Basic …), bei Zertifikaten und Schlüsseln in PEM-Dateien und bei einem Byte-Array in einem JSON-Feld.
Die Varianten, über die man stolpert
- Standard und URL-sicher. Standard-Base64 verwendet
+und/, und beide Zeichen haben in einer URL eine Bedeutung. Das URL-sichere Alphabet (RFC 4648 §5) ersetzt sie durch-und_. Wird ein Token aus dem einen Alphabet mit dem anderen dekodiert, scheitert es an genau diesen beiden Zeichen. JWTs verwenden die URL-sichere Form. - Padding. Die Länge der Ausgabe ist immer ein Vielfaches von vier und wird mit
=aufgefüllt. Manche Erzeuger lassen das Padding weg (wieder JWTs), manche Decoder verlangen es. Scheitert die Dekodierung eines ansonsten gültigen Strings, hängen Sie so lange=an, bis die Länge durch vier teilbar ist. - Zeilenumbrüche. MIME bricht nach 76 Zeichen um, PEM nach 64. Decoder ignorieren Leerraum in der Regel, aber nicht alle.
- Die Textkodierung darunter. Base64 kodiert Bytes. Um einen String in Base64 umzuwandeln, müssen Sie ihn zuerst in Bytes umwandeln, und ob das in UTF-8, UTF-16 oder Latin-1 geschieht, verändert das Ergebnis. Der klassische JavaScript-Fehler, bei dem
btoa("é")eine Ausnahme wirft, hat genau diese Ursache:btoaakzeptiert nur Latin-1. Kodieren Sie zuerst in UTF-8-Bytes.
Base64 kodieren beherrscht beide Alphabete, Padding, Zeilenumbrüche und UTF-8 und dekodiert wahlweise in Text oder in eine herunterladbare Datei. So lässt sich eine data:-URL oder ein E-Mail-Anhang im Browser in das Original zurückverwandeln.
Kodieren, Hashen, Verschlüsseln
Im Alltag werden diese drei Begriffe oft gleichbedeutend verwendet. Sie bezeichnen völlig verschiedene Dinge.
| Umkehrbar? | Braucht einen Schlüssel? | Zweck | |
|---|---|---|---|
| Kodieren (Base64, Hex, URL-Kodierung) | Ja, für jeden | Nein | Daten an einen Kanal anpassen |
| Hashen (SHA-256, MD5) | Nein | Nein | Fingerabdruck von Daten; prüfen, ob sie verändert wurden |
| Verschlüsseln (AES, RSA) | Ja, mit dem Schlüssel | Ja | Daten vor allen ohne Schlüssel geheim halten |
Mit dem Hash einer Datei prüfen Sie, ob ein Download dem entspricht, was der Anbieter bereitgestellt hat. Der Hash-Generator berechnet MD5, SHA-1 und SHA-256/384/512 im Browser und vergleicht das Ergebnis mit einer eingefügten Prüfsumme. Verborgen wird dabei nichts: Die Datei bleibt die Datei. Von den dreien sorgt allein die Verschlüsselung für Geheimhaltung, und sie ist nur so stark wie der Schlüssel. Hier kommt ein wirklich zufälliges Passwort ins Spiel.
Falls Sie gerade ein Geheimnis in Base64 umwandeln wollten
Lassen Sie es. Konkret:
- Konfigurationsdateien mit Base64-Passwörtern (ein verbreitetes Muster in älteren Java- und .NET-Anwendungen) enthalten für jeden, der die Datei öffnet, Klartext-Passwörter.
- „Verschleierte“ API-Schlüssel im Frontend-JavaScript sind im Netzwerk-Tab sichtbar, mit oder ohne Base64.
- Basic Authentication über unverschlüsseltes HTTP sendet Benutzername und Passwort Base64-kodiert, also im Klartext. Akzeptabel ist das nur innerhalb von HTTPS, wo die Transportschicht verschlüsselt.
Wenn Daten gespeichert oder übertragen werden und dabei geheim bleiben müssen, verschlüsseln Sie sie mit einem echten Verfahren (AES-256-GCM über die Krypto-Bibliothek der Plattform). Muss das Ergebnis anschließend durch einen Textkanal, kodieren Sie den Geheimtext in Base64. Kodieren nach dem Verschlüsseln ist in Ordnung. Kodieren statt Verschlüsseln ist der Fehler.
