"Base64, JWT und Hashing: Was sie wirklich sind (ohne Informatik-Studium)"

Die Lücke zwischen Etwas-Benutzen und Etwas-Verstehen

Früh in meiner Karriere debuggte ich ein Authentifizierungsproblem, als ein Senior-Entwickler fragte: "Ist der JWT abgelaufen?"

Ich sagte ja, ich hätte es überprüft. Was ich nicht zugab: Ich hatte den Token auf einer Website eingefügt, den Ablauf-Timestamp gesehen, und verstand immer noch nicht wirklich, was ich betrachtete. War er sicher? Konnte jemand den Token lesen? War er verschlüsselt? Warum konnte jede Website ihn decodieren, wenn er angeblich "signiert" und "sicher" war?

Dieser Leitfaden ist für diese frühere Version von mir. Drei Konzepte, die in der Webentwicklung ständig auftauchen, die die meisten Tutorials als bekannt voraussetzen, und die eigentlich einfach sind, sobald sie klar erklärt werden.

Base64: Keine Verschlüsselung. Keine Komprimierung. Nur Übersetzung.

Das Wichtigste zuerst: Base64 ist kein Sicherheitsmechanismus. Es versteckt deine Daten nicht. Jeder kann es sofort decodieren. Wenn du jemals dachtest "das sieht kodiert aus, also ist es wahrscheinlich sicher, es in eine URL zu stecken" — ist es nicht.

Base64 ist eine Möglichkeit, Binärdaten mit nur druckbaren ASCII-Zeichen darzustellen. Das ist alles. Der praktische Grund für seine Existenz: Binärdaten zerstören Dinge. E-Mails, HTTP-Header, URLs, HTML-Attribute — diese Systeme wurden für Text entwickelt. Rohe Binärdaten mit ihren Null-Bytes und Steuerzeichen können beim Durchlaufen textbasierter Systeme beschädigt oder verändert werden.

Base64 konvertiert Binärdaten in ein sicheres 64-Zeichen-Alphabet: A–Z, a–z, 0–9, + und /. Die Ausgabe ist etwa 33% größer als die Eingabe, aber garantiert unversehrt durch jedes Textsystem zu gelangen.

Wo du es wirklich siehst

HTTP Basic Authentication: Wenn du dich mit benutzer:passwort authentifizierst, werden die Anmeldedaten in Base64 kodiert und im Authorization: Basic-Header gesendet. Deshalb ist Basic Auth über unverschlüsseltem HTTP gefährlich — jeder, der die Anfrage abfängt, kann die Anmeldedaten sofort decodieren. HTTPS ist Pflicht.

JWT-Tokens: Jeder der drei Abschnitte eines JWT-Tokens ist in Base64url kodiert (eine Variante, die + und / durch - und _ ersetzt, um URL-sicher zu sein).

Data URIs: <img src="data:image/png;base64,iVBORw0KGgo..."> — Bilddaten direkt in HTML oder CSS einbetten, anstatt eine separate HTTP-Anfrage zu machen.

E-Mail-Anhänge: MIME-Kodierung verwendet Base64, damit Binärdateien durch E-Mail-Server reisen können, die nur für Text ausgelegt sind.

Probiere es selbst: Füge einen Text in den Base64-Encoder ein und sieh das Ergebnis. Dann füge den kodierten String zurück ein, um ihn zu decodieren. Beachte, dass die "kodierte" Version nichts versteckt — sie verwendet nur ein anderes Alphabet.

JWT: Drei Base64-Strings und eine Signatur

Ein JSON Web Token sieht so aus:

Genau zwei Punkte. Drei Abschnitte.

Header — der Teil vor dem ersten Punkt. Decodiert zu Metadaten über den Token: welcher Signierungsalgorithmus verwendet wurde, welche Art von Token es ist.

Payload — der mittlere Abschnitt. Decodiert zu den eigentlichen Claims: User-ID, E-Mail, Rollen, Ablaufzeit. Das ist es, was dein Backend liest, um den Benutzer zu identifizieren.

Signatur — der Teil nach dem zweiten Punkt. Ein kryptografischer Beweis, dass der Token nicht manipuliert wurde.

Was die meisten Entwickler überrascht

Der Payload ist in Base64url kodiert. Er ist nicht verschlüsselt. Jeder, der den Token hat, kann den Payload decodieren und seinen Inhalt lesen — User-ID, E-Mail, Rollen, Ablaufzeit, was auch immer du dort hineingesteckt hast.

Füge ein beliebiges JWT in den JWT-Decoder ein und sieh genau, was darin steckt. Es ist kein Schlüssel erforderlich.

Das überrascht die Leute, weil der String wie undurchsichtiges Kauderwelsch aussieht. Das ist er nicht. Das Sicherheitsmodell von JWT lautet: "Ich kann verifizieren, dass dieser Token tatsächlich von meinem Server ausgestellt wurde (Signaturverifizierung), also kann ich den Claims vertrauen, die er enthält. Aber diese Claims selbst sind kein Geheimnis."

Die praktische Implikation: Stecke keine Passwörter, Zahlungsdaten oder sensible persönliche Informationen in JWT-Payloads. Stecke nur das Nötigste hinein, um den Benutzer zu identifizieren und zu autorisieren.

Was die Signatur wirklich garantiert

Die Signatur wird erstellt, indem Header + Payload + ein geheimes Schlüssel, den nur dein Server kennt, durch eine Hash-Funktion geleitet werden. Wenn dein Server einen Token empfängt, berechnet er die Signatur mit demselben Geheimnis neu. Wenn die neu berechnete Signatur mit der des Tokens übereinstimmt, ist der Token echt und unverändert.

Wenn jemand den Payload ändert, um die User-ID von 123 auf 456 zu ändern, schlägt die Signaturverifizierung fehl.

Deshalb muss dein JWT-Signierungsgeheimnis wirklich geheim bleiben. Wenn ein Angreifer es erhält, kann er Tokens fälschen und sich als jeder Benutzer ausgeben.

Hashing: Einwegfunktionen

Eine Hash-Funktion nimmt eine beliebige Eingabe und erzeugt eine Ausgabe fester Größe. Zwei Eigenschaften machen sie für Sicherheit nützlich:

Deterministisch: dieselbe Eingabe erzeugt immer dieselbe Ausgabe.

Einwegig: du kannst den Hash nicht umkehren, um die ursprüngliche Eingabe zu erhalten. Es gibt kein dehash().

Ein Zeichen Unterschied. Völlig verschiedener Hash. Keine mathematische Beziehung zwischen ähnlichen Eingaben und ähnlichen Ausgaben.

Warum Passwörter gehasht, nicht verschlüsselt werden

Wenn Passwörter verschlüsselt wären, könntest du sie mit dem richtigen Schlüssel entschlüsseln. Wenn ein Angreifer deine Datenbank und deinen Verschlüsselungsschlüssel stiehlt, ist jedes Benutzerpasswort freigelegt.

Mit Hashing: Du speicherst den Hash, nicht das Passwort. Wenn ein Benutzer sich einloggt, hashst du das Eingegebene und vergleichst es mit dem gespeicherten Hash. Du musst das Original nie wiederherstellen — nur einen Versuch verifizieren.

Selbst wenn ein Angreifer deine Datenbank erhält, hat er nur Hashes. Um ein Passwort zu bekommen, muss er raten und verifizieren, was viel langsamer ist.

MD5, SHA-256, bcrypt — Warum es wichtig ist, welchen du verwendest

MD5 war in den frühen 2000ern der Standard. Jetzt ist er für Sicherheitszwecke gebrochen. Eine moderne GPU kann Milliarden von MD5-Hashes pro Sekunde berechnen, was bedeutet, dass ein Angreifer mit deiner Datenbank einfache Passwörter in Minuten knacken kann. Verwende niemals MD5 für Passwörter.

SHA-256 ist für die Integritätsprüfung geeignet — bestätigen, dass eine Datei nicht beschädigt wurde, HMAC-Signaturen für Webhooks generieren. Aber er ist zu schnell für Passwörter. Schnelles Hashing ist schlecht für Passwörter, weil es Brute-Force-Angriffe billig macht.

bcrypt wurde speziell für Passwörter entwickelt. Es ist absichtlich langsam — du kannst einstellen, wie viele Berechnungsrunden es durchführt — und enthält eingebautes "Salt" (Zufallsdaten), das sicherstellt, dass zwei identische Passwörter völlig unterschiedliche Hashes erzeugen.

Die Regel: Verwende bcrypt (oder Argon2 oder scrypt) für Passwörter. Verwende SHA-256 für alles andere, das Integritätsverifizierung benötigt.

Schnellreferenz

Diese drei Dinge richtig zu verstehen verhindert eine Klasse von Sicherheitsfehlern, die in Code-Reviews korrekt aussehen und erst in der Produktion entdeckt werden — wenn der Schaden bereits angerichtet ist.

Die Tools: Base64, JWT-Decoder, Hash-Generator. Nutze sie, um dein Verständnis zu testen, nicht nur um Ergebnisse zu erhalten.