Warum rellit.de: Werkzeuge für den sporadischen Bedarf
Manche Werkzeuge braucht man nicht täglich, sondern alle paar Wochen. Einmal schnell ein Base64 dekodieren. Ein JWT aufmachen, um zu sehen, warum die Anmeldung wieder abläuft. Nachrechnen, was 0 3 */2 * * eigentlich bedeutet. Einen Hash erzeugen, um eine Datei gegenzuprüfen.
Genau dieser sporadische Bedarf ist das Problem.
Für jeden Handgriff ein Plugin? Eher nicht.
Für all diese Aufgaben gibt es Plugins. Für jede einzelne. Und für jede IDE eine eigene Variante.
Nur rechnet sich das bei sporadischem Bedarf nicht. Ich suche ein Plugin, lese kurz quer, ob es das Richtige ist, installiere es, erlaube ihm damit, in meiner Entwicklungsumgebung mitzulaufen – und benutze es dann drei Mal im Jahr. Beim nächsten großen Update ist es nicht mehr kompatibel, oder der Autor hat das Projekt aufgegeben. Der Aufwand für Auswahl und Pflege steht in keinem Verhältnis zur Nutzung.
Dazu kommt ein Punkt, der in Entwicklerkreisen gern übersehen wird: Nicht jeder arbeitet in einer IDE. Die Kollegin im Support, die einen Token aus einem Ticket nachvollziehen muss. Der Admin, der auf einer Konsole sitzt. Jemand aus dem Test, der prüfen will, ob zwei Konfigurationen wirklich identisch sind. Der Projektleiter, der wissen will, was in diesem Token steht, über den alle reden. Alle diese Menschen haben eine sehr konkrete Frage – und keine Entwicklungsumgebung, in die sich ein Plugin einbauen ließe.
Ein Browser ist dagegen überall da.
Alles an einer Stelle
Meine Alternative war jahrelang die Suchmaschine. Für jede Aufgabe eine andere Seite, jede mit eigener Bedienlogik, jedes Mal die Frage, ob die Seite überhaupt das tut, was ich erwarte. Bei der Hälfte war nicht ersichtlich, ob die Eingabe eigentlich im Browser bleibt oder ob sie zur Verarbeitung irgendwohin geschickt wird.
Das ist spätestens dann unangenehm, wenn man einen echten Token, einen echten Hash oder einen Auszug aus einer echten Konfiguration in ein fremdes Formular einfügt.
Ich wollte die Werkzeuge, die ich brauche, an einer Stelle haben. Einheitlich bedienbar, ohne Anmeldung – und so gebaut, dass die Eingabe den Rechner gar nicht erst verlässt. Alles läuft im Browser, es gibt kein Backend, das etwas entgegennehmen könnte. Das ist nicht nur eine Datenschutzentscheidung, es ist auch die ehrlichste: Was nirgendwo hingeschickt wird, kann auch nirgendwo gespeichert werden.
Der Teil, der mich am meisten gestört hat
Das eigentliche Ärgernis war aber ein anderes.
Die meisten dieser Werkzeuge funktionieren, aber sie erklären nichts. Man wirft etwas hinein, bekommt ein Ergebnis heraus, kopiert es weg. Was dabei passiert ist, bleibt im Dunkeln – obwohl genau dieses Wissen die eigentliche Arbeit erleichtern würde.
Ein bcrypt-Generator liefert so etwas:
$2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/LewdBPj/rCWDfe1Nu
Fertig. Kopieren, einfügen, weiter. Dabei steht in dieser Zeichenkette alles Wichtige drin: 2b ist die Variante des Algorithmus. 12 ist der Kostenfaktor – der Exponent, der bestimmt, wie viel Rechenarbeit ein einzelner Hash-Vorgang kostet. Jede Erhöhung um eins verdoppelt diesen Aufwand. Danach folgen Salt und eigentlicher Hash, in einer Zeichenkette vereint. Deshalb muss der Salt nirgends separat gespeichert werden – er steht im Hash.
Wer das einmal gesehen hat, stellt beim nächsten Mal die richtige Frage. Nämlich nicht „wie erzeuge ich einen Hash”, sondern „welcher Kostenfaktor passt zu unserer Hardware und zu dem, was sich unsere Anmeldung an Antwortzeit leisten kann”.
Beim JWT ist es dasselbe. Fast jeder Decoder zeigt den Inhalt an. Deutlich weniger sagen dazu, dass der mittlere Teil lediglich Base64-kodiert und damit für jeden lesbar ist, der den Token in die Finger bekommt. Das ist keine Feinheit, das ist die zentrale Eigenschaft – und der Grund, warum Geheimnisse in einem JWT nichts verloren haben. Und die Kürzel exp, iat und nbf wären auch kein Geheimwissen, wenn irgendwo stünde, wofür sie stehen.
Deshalb steht bei meinen Werkzeugen die Erklärung gleichberechtigt neben dem Ergebnis. Nicht als ausklappbare Fußnote, sondern als Teil der Ausgabe: Was bedeutet welcher Bestandteil, warum sieht das Ergebnis so aus, worauf sollte man achten.
Der Nebeneffekt gefällt mir am besten: Man kann jemandem einen Link schicken, statt es selbst erklären zu müssen.
Was daraus geworden ist
Aus dem Gedanken ist rellit.de geworden – eine Sammlung genau der Werkzeuge, nach denen ich selbst regelmäßig gesucht habe. Konverter und Formatierer, Hashes und Kodierungen, Passwort-Hashing, JWT, Cron, reguläre Ausdrücke, Zeitstempel, Textvergleich, Farben.
Jedes Werkzeug ist eine eigenständige, statisch ausgelieferte Seite unter einer eigenen Subdomain. Kein Framework-Ballast, keine Anmeldung, kein Backend. Und zu jedem Ergebnis die Erklärung, die ich selbst gern gehabt hätte, als ich das erste Mal auf so einen Hash geschaut habe.
In den nächsten Beiträgen nehme ich einzelne davon genauer auseinander – angefangen bei der Frage, warum bcrypt und Argon2 grundsätzlich anders funktionieren als die Hash-Verfahren, die man aus dem Studium kennt.