Hash Generator — Tipps & Tricks

Zurück zur Übersicht: Hash Generator · Tool live öffnen: www.jpkc.com/tools/hash/

Das Manual erklärt jeden Algorithmus, die Beispiele zeigen die Abläufe. Hier geht es um die Einordnung, die über jedem Hash-Tool stehen sollte: welcher Algorithmus wofür, was ein Hash nicht ist, und wo die typischen Denkfehler liegen.

Die wichtigste Regel: MD5 und SHA-1 sind kryptografisch gebrochen

MD5 und SHA-1 gelten als kryptografisch unsicher. Für beide lassen sich mit vertretbarem Aufwand Kollisionen erzeugen — zwei verschiedene Eingaben mit demselben Hash. Das bedeutet konkret:

Nicht mehr verwenden für Signaturen, Zertifikate, Sicherheits-Tokens oder überall dort, wo ein Angreifer ein Interesse daran hätte, eine zweite Eingabe mit gleichem Hash unterzuschieben.
Weiterhin in Ordnung als reine Prüfsumme gegen versehentliche Veränderung — etwa um einen unbeabsichtigt beschädigten Download zu erkennen, wenn der Anbieter nun mal nur einen MD5-Wert nennt. Gegen zufällige Bitfehler taugt MD5 noch; gegen einen Angreifer nicht.

Das Tool führt MD5 und SHA-1 deshalb bewusst in der Gruppe Legacy (not collision-resistant) — zusammen mit RIPEMD-160 und CRC-32. Nutze sie mit diesem Wissen, und wo du die Wahl hast, nimm SHA-256.

Welchen Algorithmus wofür

Integrität / Prüfsummen (Standard): SHA-256. Breit unterstützt, schnell genug, sicher. Die Default-Empfehlung für Download-Verifizierung und Datei-Vergleiche.
Maximale Reserve: SHA-512 (oder SHA3-512, BLAKE2b-512) — längerer Hash, mehr Sicherheitsmarge.
SRI für <script>- und <link>-Tags: SHA-384 — das Tool bevorzugt es für die SRI-Zeile automatisch.
Moderner Standard mit anderer Konstruktion: SHA-3 (SHA3-224 bis SHA3-512). Sinnvoll, wenn explizit SHA-3 gefordert ist oder du nicht auf der SHA-2-Familie aufsetzen willst.
Keccak-256: nur, wenn ausdrücklich Keccak verlangt ist, etwa im Ethereum-Umfeld. Keccak-256 und SHA3-256 sind nicht austauschbar — gleiche Länge, andere Werte.
BLAKE2 / BLAKE3: moderne Alternativen außerhalb der SHA-Familien. Veröffentlicht ein Projekt seine Prüfsummen damit, prüfst du sie genauso über das Vergleichsfeld; im Reiter File ist BLAKE3 schon vorausgewählt.
CRC-32: nur zum Erkennen von Übertragungsfehlern oder zum Abgleich mit zip-, gzip- oder PNG-Prüfsummen. Es ist kein kryptografischer Hash und schützt nicht gegen Manipulation.
RIPEMD-160: vor allem dort relevant, wo es konkret verlangt wird. Sonst kein Grund, es SHA-256 vorzuziehen.
MD5 / SHA-1: nur, wenn die Gegenstelle es vorgibt — und nur als Integritäts-, nie als Sicherheits-Check.

Unbekannter Hash? Du musst nicht raten, welches Verfahren ihn erzeugt hat: Gib die Eingabe ins Feld Input und den Hash ins Vergleichsfeld — die Meldung „Match:" nennt das Verfahren, weil das Tool gegen alle 20 Zeilen gleichzeitig prüft.

Hashing ist weder Verschlüsselung noch Passwort-Hashing

Drei Dinge werden oft verwechselt — sie sind grundverschieden:

Hashing (Reiter Text und File) ist eine Einbahnstraße: Aus dem Hash lässt sich die Eingabe nicht zurückrechnen. Es gibt keinen „Entschlüsseln"-Knopf, weil ein Hash nichts verschlüsselt — er bildet ab. Gut für Integrität und Fingerabdrücke.
Verschlüsselung ist umkehrbar (mit Schlüssel): Klartext rein, Geheimtext raus, und mit dem Schlüssel wieder zurück. Dafür ist dieses Tool nicht zuständig — nimm den Cryptor.
Passwort-Hashing (Reiter Password hashing) ist ein eigener Anwendungsfall mit eigenen Verfahren: bcrypt, Argon2id oder PBKDF2 sind absichtlich langsam und nutzen ein Salt, um Brute-Force und Rainbow-Tables auszubremsen. Speichere Passwörter niemals als MD5/SHA aus der Ergebnistabelle — schnelle Hashes sind dafür genau das Falsche.

Kurz: Brauchst du umkehrbar, ist es Verschlüsselung. Geht es um Passwörter speichern, nimm den Reiter Password hashing. Für Fingerabdruck/Integrität sind die Reiter Text und File zuständig.

Passwort-Hashes richtig parametrieren

Argon2id ist die erste Wahl für neue Projekte — das Tool markiert es als „recommended". bcrypt bleibt solide und ist überall verbreitet; PBKDF2 brauchst du vor allem, wenn eine Umgebung (etwa Django) es erwartet.
Die Messung im Browser ist nicht die Messung auf dem Server. Die Info-Zeile nennt, wie lange der Hash hier gedauert hat, und empfiehlt einen Aufwand, der auf deinem Server etwa 0,2 bis 1 Sekunde pro Hash kostet. Dein Server kann deutlich schneller oder langsamer sein als dein Laptop — stimm Cost, Memory oder Iterations am Ende dort ab.
Argon2id-Defaults sind das Minimum. 19 MiB und 2 Iterationen entsprechen dem OWASP-Minimum; PHP selbst nimmt standardmäßig 64 MiB und 4 Iterationen. Hat dein Server den Speicher, darfst du nach oben gehen.
bcrypt kürzt bei 72 Byte. Längere Passwörter (oder Passphrasen mit vielen Umlauten, die in UTF-8 mehrere Bytes belegen) werden nur bis Byte 72 berücksichtigt. Das Tool warnt dich, wenn das passiert.
$2y$ für PHP. Erzeugst du einen bcrypt-Hash für eine PHP-Anwendung, lass den Prefix auf $2y$ (PHP). Beim Prüfen akzeptiert das Tool $2a$ , $2b$ und $2y$ gleichermaßen.
Neuer Hash bei jedem Klick ist richtig. Jeder Lauf zieht ein frisches Zufalls-Salt. Zwei unterschiedliche Strings für dasselbe Passwort sind kein Fehler — mit Verify prüfst du, dass beide passen.
Nur prüfbare Formate. Verify kennt bcrypt, Argon2id im PHC-Format und PBKDF2 im Django-Format (pbkdf2_sha256$…). Argon2i, Argon2d und scrypt prüft das Tool nicht.
Direkt hinspringen: Mit https://www.jpkc.com/tools/hash/#password öffnest du den Passwort-Reiter ohne Umweg.

HMAC richtig einsetzen

HMAC braucht ein Geheimnis. Der Wert ist nur so stark wie der Schlüssel. Tipp ihn nicht selbst aus dem Kopf — nutz den Würfel-Button neben dem Feld HMAC key, der lokal einen zufälligen 256-Bit-Schlüssel erzeugt.
Die Schlüssel-Kodierung entscheidet. Derselbe String ergibt als Text und als Hex völlig verschiedene HMACs, weil im einen Fall die Zeichen, im anderen die dekodierten Bytes der Schlüssel sind. Liefert ein Dienst sein Secret als Hex oder Base64 und rechnet intern mit den Rohbytes, stell die Kodierung entsprechend um; behandelt er den String als Text, bleib bei Text.
HMAC ≠ einfacher Hash mit angehängtem Schlüssel. HMAC hat eine eigene, gegen Length-Extension-Angriffe gehärtete Konstruktion. Genau deshalb signierst du API-Requests mit HMAC und nicht mit SHA256(schlüssel + nachricht).
HMAC-SHA-256 ist der Default für Request-Signaturen und Webhooks. Greif nur zu HMAC-MD5/HMAC-SHA-1, wenn eine Gegenstelle es ausdrücklich verlangt.
„plain" heißt: kein HMAC. SHAKE128, SHAKE256, BLAKE3 und CRC-32 zeigen auch mit Schlüssel den reinen Hash und tragen das Badge plain. Verwechsel diese Zeilen nicht mit einer Signatur.
Signatur prüfen statt vergleichen. Füg eine empfangene Signatur ins Vergleichsfeld ein; „Match: SHA-256 (HMAC)" bestätigt sie — auch wenn sie als Base64 vorliegt.

Stolperfallen aus der Praxis

Hash hängt am exakten Input. Ein unsichtbares Leerzeichen, ein Zeilenende (\n vs. \r\n) oder eine andere Zeichenkodierung ändert den Hash komplett. Wenn ein Text-Hash „nicht passt", liegt es fast immer an genau so einem unsichtbaren Unterschied. Die Info-Zeile unter dem Feld Input zeigt die Byte-Zahl — eine Abweichung um eins verrät oft ein überzähliges Zeilenende. Beachte: Das Textfeld hasht Zeilenumbrüche immer als \n (LF). Einen Text mit \r\n (CRLF) bildest du nur über Hex bytes oder den Reiter File nach.
Text-Hash ≠ Datei-Hash derselben Zeichen. Tippst du hello in das Feld Input, hasht das Tool die fünf Zeichen. Eine Datei mit dem Inhalt hello und abschließendem Zeilenumbruch ergibt einen anderen SHA-256 (5891b5b5…). Vergleiche also immer Gleiches mit Gleichem.
Datei-Verfahren vorher auswählen. Im Reiter File rechnet das Tool nur die unter Algorithms for files gewählten Verfahren. Meldet der Vergleich „the algorithm is not selected", schalte das passende Verfahren an und leg die Datei erneut ab.
Groß-/Kleinschreibung ist egal, Leerzeichen nicht. Der Vergleich ignoriert die Schreibweise und versteht Doppelpunkte als Trenner. Bei einem Leerzeichen hört er aber auf zu lesen (so funktionieren sha256sum-Zeilen). Einen in Vierergruppen mit Leerzeichen gedruckten Hash ziehst du vor dem Einfügen zusammen.
Alte SHA-3-Werte aus dem Tool. Frühere Versionen gaben unter „SHA-3" in Wahrheit Keccak aus. Passt ein früher notierter SHA3-256- oder SHA3-512-Wert nicht mehr, vergleiche ihn mit der Zeile Keccak-256 bzw. Keccak-512. Für alte SHA3-224- und SHA3-384-Werte gibt es heute keine Entsprechung.
Verlauf und Leerraum. Der optionale Verlauf speichert Texte ohne führende und abschließende Leerzeichen und Zeilenumbrüche. Holst du einen Eintrag zurück, kann der Hash deshalb vom ursprünglichen abweichen, wenn dort ein Zeilenende dabei war — und die Eingabe-Kodierung stellst du gegebenenfalls selbst wieder um.
Verlauf ausschalten heißt nicht löschen. Der Schalter blendet die Liste nur aus. Gespeicherte Einträge entfernst du mit Forget.

Mit anderen JPKCom-Tools kombinieren

Sichere Passwörter oder Schlüssel erzeugen? Der Generator liefert sie (dazu TOTP-Codes und .htpasswd-Zeilen). Den Hash fürs Speichern berechnest du anschließend hier im Reiter Password hashing.
Inhalte vertraulich machen? Das ist Verschlüsselung — dafür ist der Cryptor da.
Zertifikate, Schlüsselpaare, Signaturen? Der PKI ergänzt das Hashing um die Public-Key-Welt.

Noch mehr Kontext: die Übersicht zum großen Bild, das Manual für jeden Algorithmus und die Beispiele für die Schritt-für-Schritt-Abläufe. Ausprobieren kannst du alles direkt im Tool.