Entwicklertools · Base64-Encoder und -Decoder
Base64 ist keine Verschlüsselung: Warum ein verschlüsseltes Geheimnis für jedermann lesbar ist
· Warum es wichtig ist
base64 Sicherheit Kodierung
Base64 verbirgt nichts: Jeder, der über die Zeichenfolge verfügt, kann sie sofort und ohne Schlüssel entschlüsseln. In diesem Beitrag wird der Unterschied zwischen Codierung, Verschlüsselung und Hashing erläutert und was zu tun ist, wenn Sie Base64-Geheimnisse in einem Repository finden.
Der Konfigurationswert, der scheinbar verschlüsselt und in ein Datenbankkennwort entschlüsselt wurde – eine konkrete Entdeckung und wie schnell sie sich umkehrt
Das Auffinden von Base64 in einer Konfigurationsdatei erzeugt ein falsches Sicherheitsgefühl. Ein Entwickler entdeckt ein Datenbankkennwort, das als verschlüsselte Sequenz wie dGlnZXJfZGF0YWJhc2VfYWRtaW4 erscheint, geht davon aus, dass es verschlüsselt ist, und überträgt es zusammen mit dem Anwendungscode in das Repository. Wochen später enthüllt eine Sicherheitsüberprüfung den eigentlichen Klartext: tiger_database_admin.
Base64 verbirgt nichts; Es handelt sich um eine Verschlüsselung, nicht um eine Verschlüsselung. Dasselbe umgekehrte Passwort wird sofort wieder im Browser angezeigt, ohne Schlüssel, ohne Berechnung, ohne Verzögerung. In diesem Beitrag wird erklärt, warum es Verschlüsselung überhaupt gibt, wie sie sich grundlegend von Verschlüsselung und Hashing unterscheidet und was tatsächlich passiert, wenn jemand Base64-Geheimnisse in einem Commit-Verlauf findet.
Kodierung, Verschlüsselung und Hashing: drei verschiedene Jobs – was jeder garantiert und welcher einen Schlüssel benötigt
Die Verwirrung entsteht, weil Base64 wie ein Schutz aussieht. Ein Mensch kann nicht auf dGlnZXJfZGF0YWJhc2VfYWRtaW4 blicken und „tiger_database_admin“ lesen. Es erscheint verdeckt, bis Sie es durch einen Decoder laufen lassen. Diese oberflächliche Verschleierung fühlt sich wie Sicherheit an, ist es aber nicht. Base64 wurde entwickelt, um ein völlig anderes Problem zu lösen: das Verschieben beliebiger Binärdaten über Nur-Text-Kanäle. E-Mails, ältere Webformulare und Zeilenprotokollsysteme konnten keine Rohbytes übertragen. Base64 wandelt Bytes in druckbare ASCII-Zeichen um, sodass die Daten diese Kanäle intakt passieren können.
Sobald die Daten angekommen waren, dekodierte der Empfänger sie wieder in Bytes. Kodierung und Dekodierung sind gleichermaßen einfach; Sie erfordern keine Schlüssel, keine Entropie, keine kryptografische Bibliothek. Kodierung, Verschlüsselung und Hashing dienen drei unterschiedlichen Zwecken und bieten drei unterschiedliche Garantien. Durch die Kodierung werden Daten in eine andere Darstellung umgewandelt, sodass sie einen bestimmten Kanal durchlaufen oder in einem bestimmten Kontext verwendet werden können. Base64, URL-Kodierung, Hex-Darstellung und sogar Escape-Anführungszeichen in JSON sind alles Kodierungen. Sie sind für jedermann rückgängig zu machen und erfordern keinen geheimen Schlüssel.
Warum Base64 überhaupt existiert – sichere Übertragung von Bytes über Textkanäle, niemals Vertraulichkeit
Das Ziel ist Formatkompatibilität, nicht Vertraulichkeit. Im Gegensatz dazu erfordert die Verschlüsselung einen Schlüssel, der nur autorisierten Parteien bekannt ist. Nur jemand mit dem richtigen Schlüssel kann den Chiffretext wieder in Klartext umwandeln. Ohne den Schlüssel bleibt die Nachricht selbst für jemanden, der raffiniert genug ist, sie anzugreifen, undurchsichtig. Das Hashing ist von Natur aus einseitig: Ein kryptografischer Hash eines Passworts kann überhaupt nicht rückgängig gemacht werden. Es wird verwendet, um zu überprüfen, ob ein Passwort mit einem gespeicherten Hash übereinstimmt, ohne das Passwort selbst zu speichern.
Ein Kubernetes-Geheimnis mit dem Namen „Datenbankpasswort“, das base64 enthält: dGlnZXJfZGF0YWJhc2VfYWRtaW4, ist eigentlich kein Geheimnis. Base64 ist die Standardkodierung, die Kubernetes für die Speicherung und nicht für den Schutz verwendet. Jeder mit Zugriff auf die YAML- oder die etcd-Datenbank kann den Wert in Sekundenschnelle entschlüsseln. Bei Umgebungsvariablen mit Base64-codierten API-Schlüsseln in einem Startskript tritt dasselbe Problem auf. Ein Basic Authentication-Header, der Authorization: Basic base64_username:password an einen Server sendet, kann von jedem Proxy, Überwachungstool oder Netzwerkbeobachter zwischen Client und Server dekodiert werden.
Arbeitsbeispiel: Dekodierung einer „geheimen“ Zeichenfolge im Browser – ein Einfügen, eine Dekodierung und der Klartext, ohne Beteiligung eines Servers
Wenn der Kanal HTTP statt HTTPS ist, ist die Gefährdung noch größer. Base64 ist in diesen Zusammenhängen ein Ablenkungsmanöver: Das wahre Geheimnis wurde bereits kompromittiert, indem es überhaupt in einer wiederherstellbaren Form gespeichert oder übertragen wurde. Ein ausgearbeitetes Beispiel verdeutlicht das Problem. Angenommen, ein API-Schlüssel für einen Drittanbieterdienst erscheint in einer Konfigurationsdatei als YXBpa2V5XzEyMzQ1Njc4OTAx. Kopieren Sie diese Zeichenfolge in den Base64-Encoder und -Decoder in Ihrem Browser, fügen Sie sie in das Eingabefeld ein und klicken Sie auf „Dekodieren“.
Das Tool gibt apikey_1234567890 zurück. Dies geschah sofort in Ihrem Browser, ohne dass ein Server kontaktiert wurde, kein Schlüssel erforderlich war und keine Authentifizierung durchgeführt wurde. Der gesamte Vorgang dauert weniger als eine Sekunde. Nehmen wir nun an, dass ein böswilliger Akteur denselben Schlüssel in einem öffentlichen GitHub-Repository findet. Sie entschlüsseln es genauso einfach, in den von ihnen bevorzugten Tools, und nutzen es, um auf den Dienst zuzugreifen. Unabhängig davon, ob die Zeichenfolge in einem Repository verborgen bleibt, über ein Netzwerk übertragen wird oder in Anwendungsprotokollen erscheint, kann sie mit einer einfachen Operation aufgedeckt werden, die in jeder Programmiersprache und in Browser-Tools wie diesem verfügbar ist.
Wo dieser Fehler auftritt – Kubernetes-Geheimnisse, .env-Dateien, Basic-Authentifizierungsheader und Ressourcen für mobile Apps
Der Fehler tritt überall auf, da Base64 so häufig vorkommt, dass es mit der Verschleierung durch Nähe in Verbindung gebracht wird. Entwickler sehen Base64-codierte Daten, schließen daraus, dass jemand sie für wichtig gehalten hat, und hinterlassen Geheimnisse in dieser Form. Eine .env-Datei mit API_KEY=VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 erscheint einem Junior-Ingenieur als sicherer als API_KEY=Dies ist nicht wirklich ein Geheimnis, auch wenn die Dekodierung einen Vorgang erfordert. Mobile Anwendungen bündeln Base64-codierte Token in Ressourcen, die jeder Dekompilierer extrahieren und dekodieren kann. Datenbanksicherungen enthalten Base64-codierte Passwörter in Feldern, die durchsucht werden sollen und nicht geschützt sind.
In jedem Fall hat jemand Verschlüsselung mit Verschlüsselung verwechselt und ein Archiv mit Klartextgeheimnissen erstellt, das zufällig so formatiert ist, dass zum Lesen ein zusätzlicher Schritt erforderlich ist. Was zu tun ist, wenn Base64-Geheimnisse entdeckt werden, hängt vom Kontext ab.
Was stattdessen zu tun ist – geheime Manager, echte Verschlüsselung im Ruhezustand und Rotation aller bereits festgeschriebenen Daten
Wenn es sich bei dem Geheimnis um ein Token, einen API-Schlüssel oder ein Passwort handelt und es bereits der Versionskontrolle übergeben wurde, behandeln Sie es als gefährdet. Widerrufen Sie es, erstellen Sie ein neues und aktualisieren Sie es an jedem Ort, an dem es verwendet wurde. Der historische Commit ist Teil des permanenten Repository-Datensatzes, auch wenn das Geheimnis später in einem neuen Commit entfernt wird; Jeder, der Zugriff auf den Repository-Verlauf hat, kann es finden.
Das Durchsuchen von Repositories nach Base64-codierten Werten ist mittlerweile eine Standard-Aufklärungstaktik, sodass die Tatsache, dass etwas Base64 war, es nicht geheim macht. Verschlüsseln Sie bei laufenden Vorgängen niemals Geheimnisse mit Base64 und gehen Sie davon aus, dass sie geschützt sind. Verwenden Sie einen Secrets-Manager, der Werte verschlüsselt, zugriffskontrolliert und überprüfbar speichert. Speichern Sie im Anwendungscode und in der Konfiguration nur die Referenz oder eine Ableitung, nicht das Geheimnis selbst. Echte Verschlüsselung im Ruhezustand bedeutet, dass die Daten mit einem separat gespeicherten Schlüssel verschlüsselt werden und für jeden, der diesen Schlüssel nicht besitzt, nutzlos sind.
Was dies nicht abdeckt – Auswahl eines Verschlüsselungsalgorithmus oder Schlüsselverwaltungsdesigns
Eine Datenbank, die vertrauliche Spalten verschlüsselt, ein Secrets-Manager, der Umschlagverschlüsselung mit Schlüsseln in einem Hardware-Sicherheitsmodul verwendet, oder ein Passwort-Manager, der Verschlüsselungsschlüssel aus Benutzerkennwörtern ableitet, bieten echte Vertraulichkeit. Die Verschlüsselung auf Anwendungsebene zum Zeitpunkt der Erstellung der Geheimnisse, bevor sie irgendwo gespeichert werden, ist noch stärker. Durch die Rotierung offengelegter Geheimnisse, auch wenn sie nur Base64-codiert waren, besteht keine Möglichkeit für Missbrauch. Wenn sich ein Geheimnis in einem Repository befand, überprüfen Sie die Protokolle, um zu sehen, wann darauf zugegriffen wurde und wofür es während des Offenlegungsfensters verwendet wurde.
Für dauerhafte Sicherheit verwenden Sie kurzlebige Token, die von einem Autorisierungsdienst ausgegeben werden, und keine statischen Geheimnisse, die in der Konfiguration gespeichert sind. Ein Token, der in einer Stunde abläuft, ist für einen Angreifer weniger wertvoll, selbst wenn er kompromittiert wird. In diesem Artikel geht es nicht um die Auswahl eines Verschlüsselungsalgorithmus, des Schlüsselverwaltungsdesigns oder der Authentifizierungsarchitektur. Dabei handelt es sich um tiefergehende technische Fragen mit eigenen Standards und Kompromissen. Der Punkt ist einfacher: Base64 ist kein Werkzeug für eines dieser Probleme. Es handelt sich um eine Formatkonvertierung für Transport und Lagerung.
Takeaway: Behandeln Sie Base64 als Klartext – wie der Base64-Encoder und -Decoder den Punkt mit einem Klick vermittelt, ohne dass das Geheimnis jemals Ihren Tab verlässt
Lassen Sie sich durch das Erscheinen von Base64 in einem Repository, einer Konfigurationsdatei oder einem Protokoll nicht davon trösten, dass die Daten geschützt sind. Jedes Tool, das Text lesen kann, kann Base64 dekodieren, und der Vorgang erfolgt sofort und deterministisch. Das Lesen einer Base64-codierten Zeichenfolge als Chiffretext ist ein weit verbreitetes Missverständnis und lässt echte Geheimnisse offenkundig offen. Entwickler erkennen dies oft erst, nachdem sie Base64-Geheimnisse in der Produktion oder bei einem Audit gefunden haben. Eine neue Perspektive ergibt sich, wenn ein Ingenieur eine Beispielzeichenfolge lokal dekodiert und sieht, dass der ursprüngliche Klartext sofort erscheint.
Das Tool macht es unumgänglich: Codierung ist keine Verschlüsselung. Sobald diese Unterscheidung klar ist, erfolgt die Nachverfolgung automatisch. Jedes Base64-Geheimnis in der Codebasis muss rotiert werden. Jeder Ort, an dem dieses Geheimnis verwendet wird, muss aktualisiert werden. Das Belichtungsfenster muss beurteilt werden. In Zukunft müssen Secret Manager und echte Verschlüsselung die Verschlüsselung in dieser Rolle ersetzen. Der Base64-Encoder und -Decoder zeigt genau, wie schnell und einfach die Umkehrung erfolgt, ohne dass Ihr Geheimnis jemals den Browser verlässt. Betrachten Sie diese Leichtigkeit als die tatsächliche Sicherheitslage: Wenn Sie es in einer Sekunde entschlüsseln können, kann das auch jeder andere.