Kodierung, Hashing und Verschlüsselung sind drei verschiedene Dinge
Fast jedes Missverständnis auf dieser Seite entsteht, weil diese Begriffe als austauschbar behandelt werden. Es lohnt sich also, sie sauber zu trennen.
Kodierung ist umkehrbar und enthält kein Geheimnis. Base64 gibt es, um Binärdaten durch Kanäle zu transportieren, die nur Text annehmen – E-Mail-Anhänge, Data-URIs, JSON-Strings –, indem je drei Bytes als vier Zeichen dargestellt werden. Deshalb ist das Ergebnis immer etwa ein Drittel größer. Es gibt keinen Schlüssel. Jeder, der den String sieht, kann ihn in einem Schritt dekodieren, auch auf dieser Website. Base64 ist keine Sicherheit, keine nennenswerte Verschleierung und keine Möglichkeit, irgendetwas vor jemandem zu verbergen, der hinsieht. Prozentkodierung ist dasselbe für URLs, und hier steckt der andere häufige Fehler: Einen einzelnen Wert für einen Query-String zu kodieren ist etwas anderes, als eine fertig zusammengesetzte URL zu bereinigen, denn nur das Erste maskiert die Zeichen &, =, ? und /, die einer URL ihre Struktur geben. Wer das verwechselt, bei dem kommt „Müller & Söhne“ beim Server als zwei Parameter statt als ein Wert an.
Hashing ist eine Einbahnstraße und hat ebenfalls keinen Schlüssel. Ein Hash macht aus beliebigen Eingaben einen Fingerabdruck fester Länge, und es gibt kein Zurück – nicht weil er verschlüsselt ist, sondern weil die Information weg ist. Möglich ist nur, Eingaben zu raten und zu vergleichen, und genau deshalb sind MD5, SHA-1 und SHA-256 für das Speichern von Passwörtern falsch: Sie sind schnell, eine Grafikkarte berechnet Milliarden davon pro Sekunde, und eine gestohlene Tabelle davon wird in diesem Tempo geknackt. Passwörter brauchen eine absichtlich langsame, gesalzene Funktion – bcrypt, scrypt oder Argon2. Unabhängig davon sind MD5 und SHA-1 aus einem anderen Grund gebrochen: Zwei verschiedene Dateien mit demselben Hash lassen sich inzwischen gezielt erzeugen, daher kann keiner von beiden beweisen, dass eine Datei die erwartete ist. Um einen versehentlich beschädigten Download zu erkennen, taugen beide aber weiterhin.
Verschlüsselung ist das mit dem Schlüssel, und keines dieser Tools macht sie. Das ist kein Versäumnis. Richtige Verschlüsselung erfordert Schlüsselverwaltung, und eine Webseite ist der falsche Ort für einen Schlüssel.
Ein JWT ist signiert, nicht verschlüsselt – daran scheitern Leute ständig. Header und Payload eines Tokens sind Base64URL, also für jeden lesbar, der das Token hat, ganz ohne Schlüssel. Die Signatur verhindert, dass jemand das Token verändert; sie verhindert nicht, dass er es liest. Vertrauliches gehört also nicht in eine Payload. Daraus folgt, dass das Dekodieren eines Tokens absolut nichts über das Token beweist: Jeder kann beliebige Claims hineinschreiben und sie in Base64 umwandeln. Verifizieren heißt, die Signatur mit dem Schlüssel des Ausstellers neu zu berechnen – das macht Ihr Server, und eine Website darf nie danach fragen. Unser Decoder erweckt deshalb bewusst nicht den Eindruck einer Verifizierung und markiert die Muster, die auf ein Problem hindeuten: ein abgelaufenes Token, ein Token ganz ohne Ablaufdatum und den Algorithmus „none“, der eine dokumentierte Umgehung der Authentifizierung ist und keine Kuriosität.
JSON hat eine Zahlengenauigkeitsgrenze, in die die meisten Formatierer stillschweigend hineinlaufen. JSON selbst begrenzt die Größe einer Zahl nicht, aber eine JavaScript-Zahl ist eine 64-Bit-Gleitkommazahl, ganze Zahlen bleiben also nur bis 9.007.199.254.740.991 exakt. Eine Twitter-Post-ID, ein Discord-Snowflake, ein 64-Bit-Datenbankschlüssel oder eine Kontonummer ist größer, und wer sie durch den üblichen Einzeiler-Formatierer schickt – parsen, dann stringifizieren –, verändert ihre letzten Ziffern. Das Ergebnis sieht weiterhin wie eine plausible Zahl aus, und genau das macht es gefährlich: Aus 7205759403792793600 wird unbemerkt 7205759403792793000. Unsere JSON-Tools geben die exakten Ziffern aus, die Sie eingefügt haben, und sagen Ihnen, wie viele Zahlen sie schützen mussten.
Eine UUID-Version beschreibt, wie sie entstanden ist, nicht was sie garantiert. Nichts registriert eine UUID oder erzwingt Eindeutigkeit; die Eindeutigkeit ist eine Frage der Wahrscheinlichkeit, und die Version sagt Ihnen, woher die Bits stammen. Version 4 besteht aus 122 Bit Zufall aus dem kryptografischen Generator des Browsers. Das macht sie unerratbar und damit richtig für Links zum Zurücksetzen, Einladungscodes und alles Geheime – und falsch als Datenbankschlüssel, weil zufällige Schlüssel sich über einen sortierten Index verteilen und ihn fragmentieren. Version 7 stellt einen 48-Bit-Zeitstempel in Millisekunden an den Anfang, sodass neue Schlüssel wie ein automatisch hochgezählter Integer ans Ende des Index angehängt werden und trotzdem weltweit eindeutig bleiben. Der Haken: Eine v7-UUID verrät jedem, der sie hat, offen und auf die Millisekunde genau, wann sie erstellt wurde.
Wo ein Browser wirklich das falsche Werkzeug ist
Keines dieser dreizehn Tools sendet irgendetwas irgendwohin. Es wird keine Anfrage gestellt, nichts protokolliert, und die Seiten funktionieren auch bei getrennter Netzwerkverbindung weiter – genau deshalb lassen sie sich für eine API-Antwort voller Kundendaten oder ein Token nutzen, das Sie niemandem mailen würden. Das ist das ehrliche Argument dafür. Hier ist das ehrliche Argument dagegen.
Ein aktives Produktionsgeheimnis in eine Webseite einzufügen ist eine Angewohnheit, die man besser nicht hat – auch bei dieser. Unser Datenschutzversprechen stimmt, aber nicht ein Versprechen schützt Sie, sondern das Verhalten des Codes, und die einzig vernünftige Haltung gegenüber jeder Webseite ist: prüfen statt vertrauen. Die Prüfung kostet nichts: Trennen Sie die Internetverbindung, nachdem die Seite geladen ist, und sehen Sie zu, wie diese Tools weiterarbeiten. Ein Tool, das einen Server bräuchte, würde aufhören. Und wenn Zugangsdaten noch gültig sind und Sie sie bereits irgendwo eingefügt haben, das Sie nicht überprüfen können, ist der richtige Schritt, sie zu rotieren, nicht darüber nachzugrübeln. Für ein Token, das gerade aktiv ist, ist lokales Dekodieren – mit der Base64-Funktion Ihrer Programmiersprache oder zwei Zeilen in der Shell – besser als jede Website, unsere eingeschlossen.
Schema-Validierung. Unsere JSON- und XML-Tools prüfen, ob ein Dokument wohlgeformt ist – eine andere Frage als die, ob es einem Schema entspricht. Gegen JSON Schema oder eine XSD zu validieren heißt, eine Schemadatei abzurufen und anzuwenden, und genau diese Netzwerkanfrage stellen diese Seiten bewusst nie. Nutzen Sie ajv für JSON Schema und xmllint für XSD und DTD; beide sind kostenlos und beide können das besser, als es eine Webseite je könnte.
Alles wirklich Große oder Gestreamte. Dokumente werden vollständig im Speicher gehalten, beim Formatieren manchmal doppelt, die Obergrenze ist also der Tab. Ein paar Megabyte gehen sofort, ein paar hundert nicht. jq streamt eine JSON-Datei mit mehreren Gigabyte, die kein Browser öffnet, und ripgrep durchsucht ein ganzes Repository schneller, als Sie eine Datei einfügen können. Beim Hashing ist dieselbe Grenze noch schärfer: Die Kryptografie des Browsers kennt keinen inkrementellen Digest, die ganze Datei muss also auf einmal in den Speicher passen – ein DVD-Image scheitert, wo sha256sum, shasum oder certutil es streamen, ohne es zu merken.
Automatisierung und CI. Diese Tools laufen, wenn jemand klickt. Jede Datei in einem Repository formatieren, zehntausend UUIDs in eine Fixture schreiben oder JSON in einer Pipeline prüfen – das gehört in ein Skript: jq, xmllint, uuidgen, openssl und der base64-Befehl sind auf den meisten Rechnern schon installiert.
Alles Signierte verifizieren. Signaturprüfung, Zertifikatsketten und alles, was einen privaten Schlüssel erfordert, gehört auf Ihren Server, mit einer gepflegten Bibliothek. Diese Seite sagt Ihnen, was ein Token behauptet; sie wird Ihnen nie sagen, dass ein Token echt ist, und Sie sollten jeder Website misstrauen, die behauptet, das ohne Ihren Schlüssel zu können.
Die Wahl zwischen ähnlich klingenden Tools
JSON formatieren oder JSON-Validator? Derselbe Parser, eine andere Frage. Der Formatierer ist dafür da, ein Dokument zu lesen und umzugestalten, das sich bereits parsen lässt – einrücken, minifizieren, große Zahlen unversehrt lassen. Der Validator ist für ein Dokument, das sich nicht parsen lässt, und liefert die Zeile, die Spalte, das fehlerhafte Zeichen mit einem Zirkumflex darunter und welche der vier üblichen Ursachen es war. Wenn Sie auf „Unexpected token“ starren, brauchen Sie den Validator. Dieselbe Aufteilung gilt für XML formatieren und XML-Validator.
Base64 dekodieren oder JWT-Decoder? Ein JWT besteht aus drei Base64URL-Abschnitten, der allgemeine Decoder zeigt Ihnen also die Teile. Die JWT-Seite trennt sie für Sie, formatiert das JSON, verwandelt die Claims für Ablauf, Ausstellung und „nicht vor“ von Unix-Zeitstempeln in echte Daten in Ihrer Zeitzone, beschriftet die registrierten Claims und warnt vor Ablauf und dem Algorithmus „none“. Nehmen Sie den allgemeinen Decoder für einen Base64-Blob und die JWT-Seite für ein Token.
Base64 kodieren oder URL kodieren? Verschiedene Aufgaben, die beide „sicheren“ Text erzeugen. Base64 macht aus beliebigen Bytes Text, auf Kosten von 33 Prozent mehr Größe, und Standard-Base64 ist in einer URL überhaupt nicht sicher – seine Zeichen +, / und = haben dort alle eine Bedeutung; deshalb gibt es Base64URL. Prozentkodierung lässt lesbaren Text lesbar und maskiert nur, was die URL zerstören würde – genau das, was Sie für einen Suchbegriff, eine E-Mail-Adresse oder ein Weiterleitungsziel wollen. Eine ganze Datei für einen Query-String zu kodieren ist meist ein Zeichen dafür, dass sie in den Request-Body gehört hätte.
Hash-Generator oder UUID-Generator? Ein Hash wird aus seiner Eingabe abgeleitet, dieselbe Eingabe ergibt also immer denselben Wert – das macht ihn zum Fingerabdruck, gut zum Prüfen eines Downloads oder zum Aufspüren identischer Inhalte. Eine UUID ist frischer Zufall ohne Bezug zu irgendetwas und wiederholt sich daher nie. Wenn Sie für denselben Inhalt dieselbe Kennung wollen, bilden Sie einen Hash. Wenn Sie eine neue Kennung wollen, erzeugen Sie eine UUID.
QR-Code-Generator oder Barcode-Generator? QR ist ein zweidimensionales Raster, das beliebigen Text aufnimmt – eine URL, WLAN-Zugangsdaten, eine Telefonnummer – und von einer Smartphone-Kamera gelesen wird. Die Barcode-Seite erstellt die eindimensionalen Codes aus Handel und Logistik: EAN-13, EAN-8, UPC-A, ITF-14, Code 128 und Code 39. Die Handelsprüfziffer wird berechnet, und eine falsche oder zu kurze Nummer wird abgelehnt, statt stillschweigend zu einem gültigen Barcode für ein anderes Produkt aufgefüllt zu werden.